Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2021 - E2160. Implementing and testing import export controllers

2021-11-03T20:57:30Z

Snadend2: /* Test Plan */

=== Team ===
*Akash Sarda, aksarda
*Sairam Sakhamuri, svsakham
*Sidhant Arora, sarora22
*Sai Harsha Nadendla, snadend2

== Import and Export Functionality ==
In Expertiza, many kinds of files can be imported or exported: lists of users for whom accounts are to be created, lists of teams that have been created or need to be created, lists of topics that users are to be able to sign up for, or instructor or peer scores that have been given for a particular assignment. Historically, all of these import and export methods were written individually, using similar code patterns.
The instructor might end up adding those in excel or having that data in excel - this functionality allows the expertiza to accept that csv file and tabulate it infront of the user. The user can then select to assign columns to that data and then import it into the database.
Eg. list of topics or feedback comments from the students can be tabular if it is say a MCQ questionnaire. The instructor will then have to either enter each entry manually through the UI or can upload this file to automate it.

== Problem Description ==
Initially the different classes (Topics, Assignments, Course Participants) had different implementations of taking in the csv file which was tightly coupled with the feature / model class. However, it was discovered that instead of defining the new method again and again, this process can be automated, by pushing common code of reading the headers and writing to the database into a single generic function. This would basically make it really easy to add this functionality to other model classes and to the new features yet to come to Expertiza.

== Existing Import Functionality ==

The current import functionality is done through the ImportFileController and there are different import class methods implemented in different models that are performing import function.

In the SignUpTopic and User models use helper classes and the attributes are taken from a hash and new ActiveRecord object is created.

=== Controllers ===

*'''import_file_controller''', methods:
** Methods used to process files:
*** #get_delimiter - Sets delimiter for filetype
*** #parse_line - Processes line of the file
*** #parse_to_grid - parses the file into 2D array
*** #parse_to_hash - parses file into hash where 'header' stores header row and 'body' stores all contents.
*** #hash_rows_with_headers - Creates hash for each row of file. Keys are headers, values are row values.
** Import methods:
*** #import_from_hash - Primary import functionality. Creates objects for hashed rows (from #hash_rows_with_headers).
*** #import - Larger controller of import, sets error messages and displays.

=== Helpers ===
*'''import_file_helper''', the list of methods in the file are the following:
** ::define_attributes - Sets and returns attributes for User object from hash.
** ::create_new_user - Makes a user object in the database.

*'''import_topics_helper''', the list of methods in the file are the following:
** ::define_attributes - Sets and returns attributes for a SignUpTopic from hash.
** ::create_new_sign_up_topic - Makes SignUpTopic objects in the database.

=== Models ===

We have found that the below mentioned models are using the import functionality defined in ImportFileController. SignUpTopic and User are dependent on the helper methods to use import functionality.

*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''question'''
*'''review_response_map'''
*'''sign_up_sheet'''
*'''sign_up_topic'''
*'''user'''

== Design Plan ==

The design plan is to use Strategy patter to implement import functionality, so that all the import requests present in different models are routed through the ImportFileController. Right now since the import functionality is implemented in various model methods this leads to many if and else statements to check the type of model. So, we intent to generalize the import functionality by placing common code in the ImportFileController. But each model will still have its own import method. With this approach the redundancy is reduced by moving common code to ImportFileController and code will become DRY.

Other helper methods such as ImportFileHelper and ImportTopicHelper that are used to perform import functionality will also be removed, which keeps import functionality consistent. We will be using method overloading and overriding for the methods in ImportFileController to eliminate unnecessary if and else blocks.

To summarize our plan of changes:

* Redirect all import calls through ImportFileController
* Refactor ImportFileController by removing the redundant code and making code generic.
* Insert object creation conditions into all relevant ::import functions and into the ImportFileController form.

[[Image: DesignImport.PNG]]

== Test Plan ==
The import method has been implemented in a bunch of models which have been listed above. After preliminary analysis, we assume that the import functionality in a few of the models might have to be amended. These models are:
*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''review_response_map'''
*'''sign_up_topic'''
*'''user'''
We will update the test plan for those models in which the import code is amended to fit into the new framework. If we amend the import code in any other model, we will also update the tests in their respective .spec files to ensure 100% coverage. We also plan to create a spec file for the '''import_file_controller'''.

Similarly for the export functionality, the tests in the respective .spec files will be updated as and when the code in that model is changed.

CSC/ECE 517 Fall 2021 - E2160. Implementing and testing import export controllers

2021-11-03T20:54:07Z

Snadend2: /* Test Plan */

=== Team ===
*Akash Sarda, aksarda
*Sairam Sakhamuri, svsakham
*Sidhant Arora, sarora22
*Sai Harsha Nadendla, snadend2

== Import and Export Functionality ==
In Expertiza, many kinds of files can be imported or exported: lists of users for whom accounts are to be created, lists of teams that have been created or need to be created, lists of topics that users are to be able to sign up for, or instructor or peer scores that have been given for a particular assignment. Historically, all of these import and export methods were written individually, using similar code patterns.
The instructor might end up adding those in excel or having that data in excel - this functionality allows the expertiza to accept that csv file and tabulate it infront of the user. The user can then select to assign columns to that data and then import it into the database.
Eg. list of topics or feedback comments from the students can be tabular if it is say a MCQ questionnaire. The instructor will then have to either enter each entry manually through the UI or can upload this file to automate it.

== Problem Description ==
Initially the different classes (Topics, Assignments, Course Participants) had different implementations of taking in the csv file which was tightly coupled with the feature / model class. However, it was discovered that instead of defining the new method again and again, this process can be automated, by pushing common code of reading the headers and writing to the database into a single generic function. This would basically make it really easy to add this functionality to other model classes and to the new features yet to come to Expertiza.

== Existing Import Functionality ==

The current import functionality is done through the ImportFileController and there are different import class methods implemented in different models that are performing import function.

In the SignUpTopic and User models use helper classes and the attributes are taken from a hash and new ActiveRecord object is created.

=== Controllers ===

*'''import_file_controller''', methods:
** Methods used to process files:
*** #get_delimiter - Sets delimiter for filetype
*** #parse_line - Processes line of the file
*** #parse_to_grid - parses the file into 2D array
*** #parse_to_hash - parses file into hash where 'header' stores header row and 'body' stores all contents.
*** #hash_rows_with_headers - Creates hash for each row of file. Keys are headers, values are row values.
** Import methods:
*** #import_from_hash - Primary import functionality. Creates objects for hashed rows (from #hash_rows_with_headers).
*** #import - Larger controller of import, sets error messages and displays.

=== Helpers ===
*'''import_file_helper''', the list of methods in the file are the following:
** ::define_attributes - Sets and returns attributes for User object from hash.
** ::create_new_user - Makes a user object in the database.

*'''import_topics_helper''', the list of methods in the file are the following:
** ::define_attributes - Sets and returns attributes for a SignUpTopic from hash.
** ::create_new_sign_up_topic - Makes SignUpTopic objects in the database.

=== Models ===

We have found that the below mentioned models are using the import functionality defined in ImportFileController. SignUpTopic and User are dependent on the helper methods to use import functionality.

*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''question'''
*'''review_response_map'''
*'''sign_up_sheet'''
*'''sign_up_topic'''
*'''user'''

== Design Plan ==

The design plan is to use Strategy patter to implement import functionality, so that all the import requests present in different models are routed through the ImportFileController. Right now since the import functionality is implemented in various model methods this leads to many if and else statements to check the type of model. So, we intent to generalize the import functionality by placing common code in the ImportFileController. But each model will still have its own import method. With this approach the redundancy is reduced by moving common code to ImportFileController and code will become DRY.

Other helper methods such as ImportFileHelper and ImportTopicHelper that are used to perform import functionality will also be removed, which keeps import functionality consistent. We will be using method overloading and overriding for the methods in ImportFileController to eliminate unnecessary if and else blocks.

To summarize our plan of changes:

* Redirect all import calls through ImportFileController
* Refactor ImportFileController by removing the redundant code and making code generic.
* Insert object creation conditions into all relevant ::import functions and into the ImportFileController form.

[[Image: DesignImport.PNG]]

== Test Plan ==
As we have seen before, the import method has been implemented in a bunch of models which have been listed above. After preliminary analysis, we assume that the import functionality in a few of the models might have to be amended. These models are:
*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''review_response_map'''
*'''sign_up_topic'''
*'''user'''
We will update the test plan for those models in which the import code is amended to fit into the new framework. If we amend the import code in any other model, we will also update the tests in their respective .spec files to ensure 100% coverage. We also plan to create a spec file for the '''import_file_controller'''.

Similarly for the export functionality, the tests in the respective .spec files will be updated as and when the code in that model is changed.

CSC/ECE 517 Fall 2021 - E2160. Implementing and testing import export controllers

2021-11-03T20:53:54Z

Snadend2: /* Test Plan */

=== Team ===
*Akash Sarda, aksarda
*Sairam Sakhamuri, svsakham
*Sidhant Arora, sarora22
*Sai Harsha Nadendla, snadend2

== Import and Export Functionality ==
In Expertiza, many kinds of files can be imported or exported: lists of users for whom accounts are to be created, lists of teams that have been created or need to be created, lists of topics that users are to be able to sign up for, or instructor or peer scores that have been given for a particular assignment. Historically, all of these import and export methods were written individually, using similar code patterns.
The instructor might end up adding those in excel or having that data in excel - this functionality allows the expertiza to accept that csv file and tabulate it infront of the user. The user can then select to assign columns to that data and then import it into the database.
Eg. list of topics or feedback comments from the students can be tabular if it is say a MCQ questionnaire. The instructor will then have to either enter each entry manually through the UI or can upload this file to automate it.

== Problem Description ==
Initially the different classes (Topics, Assignments, Course Participants) had different implementations of taking in the csv file which was tightly coupled with the feature / model class. However, it was discovered that instead of defining the new method again and again, this process can be automated, by pushing common code of reading the headers and writing to the database into a single generic function. This would basically make it really easy to add this functionality to other model classes and to the new features yet to come to Expertiza.

== Existing Import Functionality ==

The current import functionality is done through the ImportFileController and there are different import class methods implemented in different models that are performing import function.

In the SignUpTopic and User models use helper classes and the attributes are taken from a hash and new ActiveRecord object is created.

=== Controllers ===

*'''import_file_controller''', methods:
** Methods used to process files:
*** #get_delimiter - Sets delimiter for filetype
*** #parse_line - Processes line of the file
*** #parse_to_grid - parses the file into 2D array
*** #parse_to_hash - parses file into hash where 'header' stores header row and 'body' stores all contents.
*** #hash_rows_with_headers - Creates hash for each row of file. Keys are headers, values are row values.
** Import methods:
*** #import_from_hash - Primary import functionality. Creates objects for hashed rows (from #hash_rows_with_headers).
*** #import - Larger controller of import, sets error messages and displays.

=== Helpers ===
*'''import_file_helper''', the list of methods in the file are the following:
** ::define_attributes - Sets and returns attributes for User object from hash.
** ::create_new_user - Makes a user object in the database.

*'''import_topics_helper''', the list of methods in the file are the following:
** ::define_attributes - Sets and returns attributes for a SignUpTopic from hash.
** ::create_new_sign_up_topic - Makes SignUpTopic objects in the database.

=== Models ===

We have found that the below mentioned models are using the import functionality defined in ImportFileController. SignUpTopic and User are dependent on the helper methods to use import functionality.

*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''question'''
*'''review_response_map'''
*'''sign_up_sheet'''
*'''sign_up_topic'''
*'''user'''

== Design Plan ==

The design plan is to use Strategy patter to implement import functionality, so that all the import requests present in different models are routed through the ImportFileController. Right now since the import functionality is implemented in various model methods this leads to many if and else statements to check the type of model. So, we intent to generalize the import functionality by placing common code in the ImportFileController. But each model will still have its own import method. With this approach the redundancy is reduced by moving common code to ImportFileController and code will become DRY.

Other helper methods such as ImportFileHelper and ImportTopicHelper that are used to perform import functionality will also be removed, which keeps import functionality consistent. We will be using method overloading and overriding for the methods in ImportFileController to eliminate unnecessary if and else blocks.

To summarize our plan of changes:

* Redirect all import calls through ImportFileController
* Refactor ImportFileController by removing the redundant code and making code generic.
* Insert object creation conditions into all relevant ::import functions and into the ImportFileController form.

[[Image: DesignImport.PNG]]

== Test Plan ==
As we have seen before, the import method has been implemented in a bunch of models which have been listed above. After preliminary analysis, we assume that the import functionality in a few of the models might have to be amended. These models are:
*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''review_response_map'''
*'''sign_up_topic'''
*'''user'''
We will update the test plan for those models in which the import code is amended to fit into the new framework. If we amend the import code in any other model, we will also update the tests in their respective .spec files to ensure 100% coverage. We also plan to create a spec file for the import_file_controller.

Similarly for the export functionality, the tests in the respective .spec files will be updated as and when the code in that model is changed.

CSC/ECE 517 Fall 2021 - E2160. Implementing and testing import export controllers

2021-11-03T20:50:02Z

Snadend2: /* Test Plan */

=== Team ===
*Akash Sarda, aksarda
*Sairam Sakhamuri, svsakham
*Sidhant Arora, sarora22
*Sai Harsha Nadendla, snadend2

== Import and Export Functionality ==
In Expertiza, many kinds of files can be imported or exported: lists of users for whom accounts are to be created, lists of teams that have been created or need to be created, lists of topics that users are to be able to sign up for, or instructor or peer scores that have been given for a particular assignment. Historically, all of these import and export methods were written individually, using similar code patterns.
The instructor might end up adding those in excel or having that data in excel - this functionality allows the expertiza to accept that csv file and tabulate it infront of the user. The user can then select to assign columns to that data and then import it into the database.
Eg. list of topics or feedback comments from the students can be tabular if it is say a MCQ questionnaire. The instructor will then have to either enter each entry manually through the UI or can upload this file to automate it.

== Problem Description ==
Initially the different classes (Topics, Assignments, Course Participants) had different implementations of taking in the csv file which was tightly coupled with the feature / model class. However, it was discovered that instead of defining the new method again and again, this process can be automated, by pushing common code of reading the headers and writing to the database into a single generic function. This would basically make it really easy to add this functionality to other model classes and to the new features yet to come to Expertiza.

== Existing Import Functionality ==

The current import functionality is done through the ImportFileController and there are different import class methods implemented in different models that are performing import function.

In the SignUpTopic and User models use helper classes and the attributes are taken from a hash and new ActiveRecord object is created.

=== Controllers ===

*'''import_file_controller''', methods:
** Methods used to process files:
*** #get_delimiter - Sets delimiter for filetype
*** #parse_line - Processes line of the file
*** #parse_to_grid - parses the file into 2D array
*** #parse_to_hash - parses file into hash where 'header' stores header row and 'body' stores all contents.
*** #hash_rows_with_headers - Creates hash for each row of file. Keys are headers, values are row values.
** Import methods:
*** #import_from_hash - Primary import functionality. Creates objects for hashed rows (from #hash_rows_with_headers).
*** #import - Larger controller of import, sets error messages and displays.

=== Helpers ===
*'''import_file_helper''', the list of methods in the file are the following:
** ::define_attributes - Sets and returns attributes for User object from hash.
** ::create_new_user - Makes a user object in the database.

*'''import_topics_helper''', the list of methods in the file are the following:
** ::define_attributes - Sets and returns attributes for a SignUpTopic from hash.
** ::create_new_sign_up_topic - Makes SignUpTopic objects in the database.

=== Models ===

We have found that the below mentioned models are using the import functionality defined in ImportFileController. SignUpTopic and User are dependent on the helper methods to use import functionality.

*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''question'''
*'''review_response_map'''
*'''sign_up_sheet'''
*'''sign_up_topic'''
*'''user'''

== Design Plan ==

The design plan is to use Strategy patter to implement import functionality, so that all the import requests present in different models are routed through the ImportFileController. Right now since the import functionality is implemented in various model methods this leads to many if and else statements to check the type of model. So, we intent to generalize the import functionality by placing common code in the ImportFileController. But each model will still have its own import method. With this approach the redundancy is reduced by moving common code to ImportFileController and code will become DRY.

Other helper methods such as ImportFileHelper and ImportTopicHelper that are used to perform import functionality will also be removed, which keeps import functionality consistent. We will be using method overloading and overriding for the methods in ImportFileController to eliminate unnecessary if and else blocks.

To summarize our plan of changes:

* Redirect all import calls through ImportFileController
* Refactor ImportFileController by removing the redundant code and making code generic.
* Insert object creation conditions into all relevant ::import functions and into the ImportFileController form.

[[Image: DesignImport.PNG]]

== Test Plan ==
As we have seen before, the import method has been implemented in a bunch of models which have been listed above. After preliminary analysis, we assume that the import functionality in a few of the models might have to be amended. These models are:
*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''review_response_map'''
*'''sign_up_topic'''
*'''user'''
We will update the test plan for those models in which the import code is amended to fit into the new framework. If we amend the import code in any other model, we will also update the tests in their respective .spec files to ensure 100% coverage.

Similarly for the export functionality, the tests in the respective .spec files will be updated as and when the code in that model is changed.

CSC/ECE 517 Fall 2021 - E2160. Implementing and testing import export controllers

2021-11-03T20:48:38Z

Snadend2: /* Test Plan */

=== Team ===
*Akash Sarda, aksarda
*Sairam Sakhamuri, svsakham
*Sidhant Arora, sarora22
*Sai Harsha Nadendla, snadend2

== Import and Export Functionality ==
In Expertiza, many kinds of files can be imported or exported: lists of users for whom accounts are to be created, lists of teams that have been created or need to be created, lists of topics that users are to be able to sign up for, or instructor or peer scores that have been given for a particular assignment. Historically, all of these import and export methods were written individually, using similar code patterns.
The instructor might end up adding those in excel or having that data in excel - this functionality allows the expertiza to accept that csv file and tabulate it infront of the user. The user can then select to assign columns to that data and then import it into the database.
Eg. list of topics or feedback comments from the students can be tabular if it is say a MCQ questionnaire. The instructor will then have to either enter each entry manually through the UI or can upload this file to automate it.

== Problem Description ==
Initially the different classes (Topics, Assignments, Course Participants) had different implementations of taking in the csv file which was tightly coupled with the feature / model class. However, it was discovered that instead of defining the new method again and again, this process can be automated, by pushing common code of reading the headers and writing to the database into a single generic function. This would basically make it really easy to add this functionality to other model classes and to the new features yet to come to Expertiza.

== Existing Import Functionality ==

The current import functionality is done through the ImportFileController and there are different import class methods implemented in different models that are performing import function.

In the SignUpTopic and User models use helper classes and the attributes are taken from a hash and new ActiveRecord object is created.

=== Controllers ===

*'''import_file_controller''', methods:
** Methods used to process files:
*** #get_delimiter - Sets delimiter for filetype
*** #parse_line - Processes line of the file
*** #parse_to_grid - parses the file into 2D array
*** #parse_to_hash - parses file into hash where 'header' stores header row and 'body' stores all contents.
*** #hash_rows_with_headers - Creates hash for each row of file. Keys are headers, values are row values.
** Import methods:
*** #import_from_hash - Primary import functionality. Creates objects for hashed rows (from #hash_rows_with_headers).
*** #import - Larger controller of import, sets error messages and displays.

=== Helpers ===
*'''import_file_helper''', the list of methods in the file are the following:
** ::define_attributes - Sets and returns attributes for User object from hash.
** ::create_new_user - Makes a user object in the database.

*'''import_topics_helper''', the list of methods in the file are the following:
** ::define_attributes - Sets and returns attributes for a SignUpTopic from hash.
** ::create_new_sign_up_topic - Makes SignUpTopic objects in the database.

=== Models ===

We have found that the below mentioned models are using the import functionality defined in ImportFileController. SignUpTopic and User are dependent on the helper methods to use import functionality.

*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''question'''
*'''review_response_map'''
*'''sign_up_sheet'''
*'''sign_up_topic'''
*'''user'''

== Design Plan ==

The design plan is to use Strategy patter to implement import functionality, so that all the import requests present in different models are routed through the ImportFileController. Right now since the import functionality is implemented in various model methods this leads to many if and else statements to check the type of model. So, we intent to generalize the import functionality by placing common code in the ImportFileController. But each model will still have its own import method. With this approach the redundancy is reduced by moving common code to ImportFileController and code will become DRY.

Other helper methods such as ImportFileHelper and ImportTopicHelper that are used to perform import functionality will also be removed, which keeps import functionality consistent. We will be using method overloading and overriding for the methods in ImportFileController to eliminate unnecessary if and else blocks.

To summarize our plan of changes:

* Redirect all import calls through ImportFileController
* Refactor ImportFileController by removing the redundant code and making code generic.
* Insert object creation conditions into all relevant ::import functions and into the ImportFileController form.

[[Image: DesignImport.PNG]]

== Test Plan ==
As we have seen before, the import method has been implemented in a bunch of models which have been listed above. After preliminary analysis, we assume that the import functionality in a few of the models might have to be amended. These models are:
*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''review_response_map'''
*'''sign_up_topic'''
*'''user'''
We will update the test plan for those models in which the import code is amended to fit into the new framework. If we amend the import code in any other model, we will also update the tests in their respective .spec files.
Similarly for the export functionality, the tests in the respective .spec files will be updated as and when the code in that model is changed.

CSC/ECE 517 Fall 2021 - E2160. Implementing and testing import export controllers

2021-11-03T20:43:54Z

Snadend2: /* Test Plan */

=== Team ===
*Akash Sarda, aksarda
*Sairam Sakhamuri, svsakham
*Sidhant Arora, sarora22
*Sai Harsha Nadendla, snadend2

== Import and Export Functionality ==
In Expertiza, many kinds of files can be imported or exported: lists of users for whom accounts are to be created, lists of teams that have been created or need to be created, lists of topics that users are to be able to sign up for, or instructor or peer scores that have been given for a particular assignment. Historically, all of these import and export methods were written individually, using similar code patterns.
The instructor might end up adding those in excel or having that data in excel - this functionality allows the expertiza to accept that csv file and tabulate it infront of the user. The user can then select to assign columns to that data and then import it into the database.
Eg. list of topics or feedback comments from the students can be tabular if it is say a MCQ questionnaire. The instructor will then have to either enter each entry manually through the UI or can upload this file to automate it.

== Problem Description ==
Initially the different classes (Topics, Assignments, Course Participants) had different implementations of taking in the csv file which was tightly coupled with the feature / model class. However, it was discovered that instead of defining the new method again and again, this process can be automated, by pushing common code of reading the headers and writing to the database into a single generic function. This would basically make it really easy to add this functionality to other model classes and to the new features yet to come to Expertiza.

== Existing Import Functionality ==

The current import functionality is done through the ImportFileController and there are different import class methods implemented in different models that are performing import function.

In the SignUpTopic and User models use helper classes and the attributes are taken from a hash and new ActiveRecord object is created.

=== Controllers ===

*'''import_file_controller''', methods:
** Methods used to process files:
*** #get_delimiter - Sets delimiter for filetype
*** #parse_line - Processes line of the file
*** #parse_to_grid - parses the file into 2D array
*** #parse_to_hash - parses file into hash where 'header' stores header row and 'body' stores all contents.
*** #hash_rows_with_headers - Creates hash for each row of file. Keys are headers, values are row values.
** Import methods:
*** #import_from_hash - Primary import functionality. Creates objects for hashed rows (from #hash_rows_with_headers).
*** #import - Larger controller of import, sets error messages and displays.

=== Helpers ===
*'''import_file_helper''', the list of methods in the file are the following:
** ::define_attributes - Sets and returns attributes for User object from hash.
** ::create_new_user - Makes a user object in the database.

*'''import_topics_helper''', the list of methods in the file are the following:
** ::define_attributes - Sets and returns attributes for a SignUpTopic from hash.
** ::create_new_sign_up_topic - Makes SignUpTopic objects in the database.

=== Models ===

We have found that the below mentioned models are using the import functionality defined in ImportFileController. SignUpTopic and User are dependent on the helper methods to use import functionality.

*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''question'''
*'''review_response_map'''
*'''sign_up_sheet'''
*'''sign_up_topic'''
*'''user'''

== Design Plan ==

The design plan is to use Strategy patter to implement import functionality, so that all the import requests present in different models are routed through the ImportFileController. Right now since the import functionality is implemented in various model methods this leads to many if and else statements to check the type of model. So, we intent to generalize the import functionality by placing common code in the ImportFileController. But each model will still have its own import method. With this approach the redundancy is reduced by moving common code to ImportFileController and code will become DRY.

Other helper methods such as ImportFileHelper and ImportTopicHelper that are used to perform import functionality will also be removed, which keeps import functionality consistent. We will be using method overloading and overriding for the methods in ImportFileController to eliminate unnecessary if and else blocks.

To summarize our plan of changes:

* Redirect all import calls through ImportFileController
* Refactor ImportFileController by removing the redundant code and making code generic.
* Insert object creation conditions into all relevant ::import functions and into the ImportFileController form.

[[Image: DesignImport.PNG]]

== Test Plan ==
As we have seen before, the import method has been implemented in a bunch of models which have been listed above. After preliminary analysis, we noticed that we should change the models and implement them in the new framework. These models are:
*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''review_response_map'''
*'''sign_up_topic'''
*'''user'''
We will update the test plan for those models in which the import code is amended to fit into the new framework.
If we amend the import code in any other model, we will also update the tests in their respective .spec files.

CSC/ECE 517 Fall 2021 - E2160. Implementing and testing import export controllers

2021-11-03T20:42:14Z

Snadend2:

=== Team ===
*Akash Sarda, aksarda
*Sairam Sakhamuri, svsakham
*Sidhant Arora, sarora22
*Sai Harsha Nadendla, snadend2

== Import and Export Functionality ==
In Expertiza, many kinds of files can be imported or exported: lists of users for whom accounts are to be created, lists of teams that have been created or need to be created, lists of topics that users are to be able to sign up for, or instructor or peer scores that have been given for a particular assignment. Historically, all of these import and export methods were written individually, using similar code patterns.
The instructor might end up adding those in excel or having that data in excel - this functionality allows the expertiza to accept that csv file and tabulate it infront of the user. The user can then select to assign columns to that data and then import it into the database.
Eg. list of topics or feedback comments from the students can be tabular if it is say a MCQ questionnaire. The instructor will then have to either enter each entry manually through the UI or can upload this file to automate it.

== Problem Description ==
Initially the different classes (Topics, Assignments, Course Participants) had different implementations of taking in the csv file which was tightly coupled with the feature / model class. However, it was discovered that instead of defining the new method again and again, this process can be automated, by pushing common code of reading the headers and writing to the database into a single generic function. This would basically make it really easy to add this functionality to other model classes and to the new features yet to come to Expertiza.

== Existing Import Functionality ==

The current import functionality is done through the ImportFileController and there are different import class methods implemented in different models that are performing import function.

In the SignUpTopic and User models use helper classes and the attributes are taken from a hash and new ActiveRecord object is created.

=== Controllers ===

*'''import_file_controller''', methods:
** Methods used to process files:
*** #get_delimiter - Sets delimiter for filetype
*** #parse_line - Processes line of the file
*** #parse_to_grid - parses the file into 2D array
*** #parse_to_hash - parses file into hash where 'header' stores header row and 'body' stores all contents.
*** #hash_rows_with_headers - Creates hash for each row of file. Keys are headers, values are row values.
** Import methods:
*** #import_from_hash - Primary import functionality. Creates objects for hashed rows (from #hash_rows_with_headers).
*** #import - Larger controller of import, sets error messages and displays.

=== Helpers ===
*'''import_file_helper''', the list of methods in the file are the following:
** ::define_attributes - Sets and returns attributes for User object from hash.
** ::create_new_user - Makes a user object in the database.

*'''import_topics_helper''', the list of methods in the file are the following:
** ::define_attributes - Sets and returns attributes for a SignUpTopic from hash.
** ::create_new_sign_up_topic - Makes SignUpTopic objects in the database.

=== Models ===

We have found that the below mentioned models are using the import functionality defined in ImportFileController. SignUpTopic and User are dependent on the helper methods to use import functionality.

*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''question'''
*'''review_response_map'''
*'''sign_up_sheet'''
*'''sign_up_topic'''
*'''user'''

== Design Plan ==

The design plan is to use Strategy patter to implement import functionality, so that all the import requests present in different models are routed through the ImportFileController. Right now since the import functionality is implemented in various model methods this leads to many if and else statements to check the type of model. So, we intent to generalize the import functionality by placing common code in the ImportFileController. But each model will still have its own import method. With this approach the redundancy is reduced by moving common code to ImportFileController and code will become DRY.

Other helper methods such as ImportFileHelper and ImportTopicHelper that are used to perform import functionality will also be removed, which keeps import functionality consistent. We will be using method overloading and overriding for the methods in ImportFileController to eliminate unnecessary if and else blocks.

To summarize our plan of changes:

* Redirect all import calls through ImportFileController
* Refactor ImportFileController by removing the redundant code and making code generic.
* Insert object creation conditions into all relevant ::import functions and into the ImportFileController form.

[[Image: DesignImport.PNG]]

== Test Plan ==
As we have seen before, the import method has been implemented in a bunch of models which have been listed above. After preliminary analysis, we noticed that we should change the models and implement them in the new framework. These models are:
*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''review_response_map'''
*'''sign_up_topic'''
*'''user'''
We will update the test plan for those models in which the import code is amended to fit into the new framework.

CSC/ECE 517 Fall 2021 - E2117. Refactor questionaires controller.rb

2021-10-27T04:06:25Z

Snadend2: /* Changes made */

__TOC__

==Introduction==

===About Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source project developed using a [http://rubyonrails.org/ Ruby on Rails] framework. In Expertiza, an instructor can create, delete or edit new and existing assignments and also create topics for the students to sign up for or assign them to particular groups or individual students. A student can create teams to work on projects and assignments, and also peer review other's work. The website allows submission of various file type and also URL's.

===About questionnaire_controller.rb===
Questionnaire is the superclass for all kinds of [https://expertiza.csc.ncsu.edu/index.php/Questionnaires] and rubrics—rubrics for evaluating submissions and teammate contributions, and taking quizzes and surveys. All of these are subclasses of Questionnaire. questionnaires_controller.rb is charged with creating, displaying, and managing Questionnaires. Since it is used so widely, malfunctions could cause bugs in many parts of the system; hence it is especially important that the code be clear.

==Issues to be addressed==
*Investigate the need and usage of the method create_questionnaire
*Refactor the create method into different methods with self-descriptive names for easier understanding
*The display_type attribute that was being set in the create method is never actually being used and is instead being overwritten by a post_initialization method on the types of objects being created.
*Investigate the usage of checks for whether a questionnaire is '''QuizQuestionnaire'''
*Replace hard-coded rubric criteria scoring
*Investigate usage of questionnaire_id parameter
*Bad if statements
*Refactor save_all_questions method - Cognitive Complexity and Assignment Branch Condition exceed allowed limit.
*Refactor copy method - Assignment Branch Condition is too high.

==Changes made==
*In none of the files was the create_questionaire method being called so it was deleted.
*Removed the display_type attribute and added a display_type method that pulls the correct display_type string from the subclass that is being utilized.
*Removed the Rubric class as it wasn't being used as far as I could tell. This will need to be verified by the running a query on the production database.
*'''All the other issues couldn't be addressed due to a problem of bigger scope popping up under the notice of the instructor and we moved our focus onto solving that and didn't have enough time left to deal with the original issues.'''

==Future Work==
*The Questionnaire table still has the display_type attribute and will need to be removed after an exploration of the data has been taken and verified that all display_types are represented by subclasses available.

==Team Members==
*Isha Gupta
*John Marsden
*Sai Harsha Nadendla

CSC/ECE 517 Fall 2021 - E2117. Refactor questionaires controller.rb

2021-10-21T02:55:28Z

Snadend2:

CSC/ECE 517 Fall 2021 - E2117. Refactor questionaires controller.rb

2021-10-21T02:54:54Z

Snadend2: /* Changes made */

CSC/ECE 517 Fall 2021 - E2117. Refactor questionaires controller.rb

2021-10-21T02:53:15Z

Snadend2:

CSC/ECE 517 Fall 2021 - E2117. Refactor questionaires controller.rb

2021-10-21T02:49:39Z

Snadend2:

CSC/ECE 517 Fall 2021 - E2117. Refactor questionaires controller.rb

2021-10-21T02:47:10Z

Snadend2: /* Changes made */

CSC/ECE 517 Fall 2021 - E2117. Refactor questionaires controller.rb

2021-10-21T02:43:38Z

Snadend2: Created page with "__TOC__ ==Introduction== ===About Expertiza=== [http://expertiza.ncsu.edu/ Expertiza] is an open source project developed using a [http://rubyonrails.org/ Ruby on Rails] fra..."

CSC/ECE 517 Fall 2021

2021-10-20T23:39:58Z

Snadend2:

== OSS Projects ==
* [[CSC/ECE 517 Fall 2021 - {$num}. {$desc.title}]]
* [[CSC/ECE 517 Fall 2021 - E2117. Refactor questionaires_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2128. Refactor student_quizzes_controller.rb & late_policies_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2132. Add tests cases for review mapping helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2134. Write unit tests for admin_controller.rb and institution_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2138. Auto-generate submission directory names based on assignment]]
* [[CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications]]
* [[CSC/ECE 517 Fall 2021 - E2133. Write tests for popup_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2120. Refactor reputation_web_service_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2139. Remove multiple topics at a time]]
* [[CSC/ECE 517 Fall 2021 - E2131. Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2121. Refactor suggestion_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2122. Refactor impersonate_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2126. Refactor account_request_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2124. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2125. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2127. Refactor teams_controller]]
* [[CSC/ECE 517 Fall 2021 - E2130. Refactor submitted_content_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2141. OSS project Finklestein: Instructors & Institutions]]
* [[CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing]]
* [[CSC/ECE 517 Fall 2021 - E2145. OSS Project Beige]]