Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-14T04:22:55Z

Rsinha2: /* Design */

=Introduction=
==Purpose==
'''Scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

==Scope==
The project provides instructor a functionality to make assignment reviews to be anonymous or non-anonymous. In addition, instructors have authority to create and assign review groups (students assigned same review group will review each others work) randomly.This scenario will be valid for individual assignments only. Also, anonymity is taken care from the perspective of reviewer as well as the reviewee. In case of non-anonymous groups, students may have the option to invite other students to join their group provided group size is not exceeding the maximum limit.

==Background==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Design=

'''Assignment Creation:'''

Providing a checkbox in "review strategy tab" to mark an assignment to have anonymous or non-anonymous reviews. By default, every assignment will be having anonymous reviews but an instructor can change it by unchecking the checkbox (Anonymous would be boolean field present in the group model).

'''Group Formation:'''

The instructor has the authority to create and assign groups randomly. In this case, students can not drop the group they have been assigned and only an instructor can change their group if needed.
In case, a group has not been assigned by an instructor, students will have the functionality to invite other students to join their group. This functionality is analogous to the invite members to join their team.
Students in the same group can review work of their group members only.

For this, we will be creating a separate model for groups and will store all the group information into the corresponding database table. In order to follow the DRY principle, we will try to integrate the group code with the code written for teams.

[[File:UML-1.png]]

'''Non Anonymous Reviews'''

In the case of non-anonymous reviews, students will be able to see the names of all the group members who have graded their individual work. In addition, students can also see whose work they are going to grade so that the non-anonymity is maintained from both sides.

*This is the view of the review strategy tab where the checkbox for anonymity has to be added

[[File:viewToBeChanged1.png]]

*This is the view where names would be visible to ensure non anonymity of reviews

[[File:New1234.png]]

===Experimental Use===

This project is part of an experiment to test whether anonymity makes a difference in reviews of students, thus to implement it one assignment would be made as anonymous and another as anonymous and the quality and the review scores would be tested to say if there is a change in quality and values of control and test

= UI Testing =
The project can be tested by doing the following:

Log in as Instructor using instructor6
use password as password
click on manage assignments
Go to any assignment and edit
click on the review strategy tab
uncheck anonymity to disable anonymous reviews

On the student side
log in as student
click on assignments
select your scores
select view reviews

when you check your scores for each review when you log in as a student
you should see the name of the reviewer
appended to review 1

=Files to be Considered=
*controller/reveiw_mapping_controller.rb

*controller/teams_controller.rb

*model/team.rb

*views/assignments/edit/_review_strategy.html.erb

*views/grades/_reviews.html.erb

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-11T21:10:54Z

Rsinha2: /* Files to be Considered */

=Introduction=
==Purpose==
'''Scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

==Scope==
The project provides instructor a functionality to make assignment reviews to be anonymous or non-anonymous. In addition, instructors have authority to create and assign review groups (students assigned same review group will review each others work) randomly.This scenario will be valid for individual assignments only. Also, anonymity is taken care from the perspective of reviewer as well as the reviewee. In case of non-anonymous groups, students may have the option to invite other students to join their group provided group size is not exceeding the maximum limit.

==Background==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Design=

'''Assignment Creation:'''

Providing a checkbox in "review strategy tab" to mark an assignment to have anonymous or non-anonymous reviews. By default, every assignment will be having anonymous reviews but an instructor can change it by unchecking the checkbox.

'''Group Formation:'''

The instructor has the authority to create and assign groups randomly. In this case, students can not drop the group they have been assigned and only an instructor can change their group if needed.
In case, a group has not been assigned by an instructor, students will have the functionality to invite other students to join their group. This functionality is analogous to the invite members to join their team.
Students in the same group can review work of their group members only.

For this, we will be creating a separate model for groups and will store all the group information into the corresponding database table. In order to follow the DRY principle, we will try to integrate the group code with the code written for teams.

'''Non Anonymous Reviews'''

In the case of non-anonymous reviews, students will be able to see the names of all the group members who have graded their individual work. In addition, students can also see whose work they are going to grade so that the non-anonymity is maintained from both sides.

*This is the view of the review strategy tab where the checkbox for anonymity has to be added

[[File:viewToBeChanged1.png]]

*This is the view where names would be visible to ensure non anonymity of reviews

[[File:New1234.png]]

===Experimental Use===

This project is part of an experiment to test whether anonymity makes a difference in reviews of students, thus to implement it one assignment would be made as anonymous and another as anonymous and the quality and the review scores would be tested to say if there is a change in quality and values of control and test

= UI Testing =
The project can be tested by doing the following:

Log in as Instructor using instructor6
use password as password
click on manage assignments
Go to any assignment and edit
click on the review strategy tab
uncheck anonymity to disable anonymous reviews

On the student side
log in as student
click on assignments
select your scores
select view reviews

when you check your scores for each review when you log in as a student
you should see the name of the reviewer
appended to review 1

=Files to be Considered=
*controller/reveiw_mapping_controller.rb

*controller/teams_controller.rb

*model/team.rb

*views/assignments/edit/_review_strategy.html.erb

*views/grades/_reviews.html.erb

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-11T19:28:53Z

Rsinha2: /* Files to be Considered */

=Introduction=
==Purpose==
'''Scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

==Scope==
The project provides instructor a functionality to make assignment reviews to be anonymous or non-anonymous. In addition, instructors have authority to create and assign review groups (students assigned same review group will review each others work) randomly.This scenario will be valid for individual assignments only. Also, anonymity is taken care from the perspective of reviewer as well as the reviewee. In case of non-anonymous groups, students may have the option to invite other students to join their group provided group size is not exceeding the maximum limit.

==Background==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Design=

'''Assignment Creation:'''

Providing a checkbox in "review strategy tab" to mark an assignment to have anonymous or non-anonymous reviews. By default, every assignment will be having anonymous reviews but an instructor can change it by unchecking the checkbox.

'''Group Formation:'''

The instructor has the authority to create and assign groups randomly. In this case, students can not drop the group they have been assigned and only an instructor can change their group if needed.
In case, a group has not been assigned by an instructor, students will have the functionality to invite other students to join their group. This functionality is analogous to the invite members to join their team.
Students in the same group can review work of their group members only.

For this, we will be creating a separate model for groups and will store all the group information into the corresponding database table. In order to follow the DRY principle, we will try to integrate the group code with the code written for teams.

'''Non Anonymous Reviews'''

In the case of non-anonymous reviews, students will be able to see the names of all the group members who have graded their individual work. In addition, students can also see whose work they are going to grade so that the non-anonymity is maintained from both sides.

*This is the view of the review strategy tab where the checkbox for anonymity has to be added

[[File:viewToBeChanged1.png]]

*This is the view where names would be visible to ensure non anonymity of reviews

[[File:New1234.png]]

===Experimental Use===

This project is part of an experiment to test whether anonymity makes a difference in reviews of students, thus to implement it one assignment would be made as anonymous and another as anonymous and the quality and the review scores would be tested to say if there is a change in quality and values of control and test

=Files to be Considered=
*controller/reveiw_mapping_controller.rb

*controller/teams_controller.rb

*model/team.rb

*views/assignments/edit/_review_strategy.html.erb

*views/grades/_reviews.html.erb

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-11T19:28:00Z

Rsinha2: /* Design */

=Introduction=
==Purpose==
'''Scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

==Scope==
The project provides instructor a functionality to make assignment reviews to be anonymous or non-anonymous. In addition, instructors have authority to create and assign review groups (students assigned same review group will review each others work) randomly.This scenario will be valid for individual assignments only. Also, anonymity is taken care from the perspective of reviewer as well as the reviewee. In case of non-anonymous groups, students may have the option to invite other students to join their group provided group size is not exceeding the maximum limit.

==Background==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Design=

'''Assignment Creation:'''

Providing a checkbox in "review strategy tab" to mark an assignment to have anonymous or non-anonymous reviews. By default, every assignment will be having anonymous reviews but an instructor can change it by unchecking the checkbox.

'''Group Formation:'''

The instructor has the authority to create and assign groups randomly. In this case, students can not drop the group they have been assigned and only an instructor can change their group if needed.
In case, a group has not been assigned by an instructor, students will have the functionality to invite other students to join their group. This functionality is analogous to the invite members to join their team.
Students in the same group can review work of their group members only.

For this, we will be creating a separate model for groups and will store all the group information into the corresponding database table. In order to follow the DRY principle, we will try to integrate the group code with the code written for teams.

'''Non Anonymous Reviews'''

In the case of non-anonymous reviews, students will be able to see the names of all the group members who have graded their individual work. In addition, students can also see whose work they are going to grade so that the non-anonymity is maintained from both sides.

*This is the view of the review strategy tab where the checkbox for anonymity has to be added

[[File:viewToBeChanged1.png]]

*This is the view where names would be visible to ensure non anonymity of reviews

[[File:New1234.png]]

===Experimental Use===

This project is part of an experiment to test whether anonymity makes a difference in reviews of students, thus to implement it one assignment would be made as anonymous and another as anonymous and the quality and the review scores would be tested to say if there is a change in quality and values of control and test

=Files to be Considered=
*reveiw_mapping_controller.rb

*teams_controller.rb

*team.rb

*views/assignments/edit/_review_strategy.html.erb

*views/grades/_reviews.html.erb

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-11T19:25:30Z

Rsinha2: /* Design */

=Introduction=
==Purpose==
'''Scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

==Scope==
The project provides instructor a functionality to make assignment reviews to be anonymous or non-anonymous. In addition, instructors have authority to create and assign review groups (students assigned same review group will review each others work) randomly.This scenario will be valid for individual assignments only. Also, anonymity is taken care from the perspective of reviewer as well as the reviewee. In case of non-anonymous groups, students may have the option to invite other students to join their group provided group size is not exceeding the maximum limit.

==Background==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Design=

'''Assignment Creation:'''

Providing a checkbox in "review strategy tab" to mark an assignment to have anonymous or non-anonymous reviews. By default, every assignment will be having anonymous reviews but an instructor can change it by unchecking the checkbox.

'''Group Formation:'''

The instructor has the authority to create and assign groups randomly. In this case, students can not drop the group they have been assigned and only an instructor can change their group if needed.
In case, a group has not been assigned by an instructor, students will have the functionality to invite other students to join their group. This functionality is analogous to the invite members to join their team.
Students in the same group can review work of their group members only.

For this, we will be creating a separate model for groups and will store all the group information into the corresponding database table. In order to follow the DRY principle, we will try to integrate the group code with the code written for teams.

'''Non Anonymous Reviews'''

In the case of non-anonymous reviews, students will be able to see the names of all the group members who have graded their individual work. In addition, students can also see whose work they are going to grade so that the non-anonymity is maintained from both sides.

*This is the view of the review strategy tab where the checkbox for anonymity has to be added

[[File:viewToBeChanged1.png]]

*This is the view where names would be visible to ensure non anonymity of reviews

[[File:New1234.png]]

=Files to be Considered=
*reveiw_mapping_controller.rb

*teams_controller.rb

*team.rb

*views/assignments/edit/_review_strategy.html.erb

*views/grades/_reviews.html.erb

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-11T19:22:11Z

Rsinha2: /* Design */

=Introduction=
==Purpose==
'''Scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

==Scope==
The project provides instructor a functionality to make assignment reviews to be anonymous or non-anonymous. In addition, instructors have authority to create and assign review groups (students assigned same review group will review each others work) randomly.This scenario will be valid for individual assignments only. Also, anonymity is taken care from the perspective of reviewer as well as the reviewee. In case of non-anonymous groups, students may have the option to invite other students to join their group provided group size is not exceeding the maximum limit.

==Background==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Design=

'''Assignment Creation:'''

Providing a checkbox in "review strategy tab" to mark an assignment to have anonymous or non-anonymous reviews. By default, every assignment will be having anonymous reviews but an instructor can change it by unchecking the checkbox.

'''Group Formation:'''

The instructor has the authority to create and assign groups randomly. In this case, students can not drop the group they have been assigned and only an instructor can change their group if needed.
In case, a group has not been assigned by an instructor, students will have the functionality to invite other students to join their group. This functionality is analogous to the invite members to join their team.
Students in the same group can review work of their group members only.

For this, we will be creating a separate model for groups and will store all the group information into the corresponding database table. In order to follow the DRY principle, we will try to integrate the group code with the code written for teams.

'''Non Anonymous Reviews'''

In the case of non-anonymous reviews, students will be able to see the names of all the group members who have graded their individual work. In addition, students can also see whose work they are going to grade so that the non-anonymity is maintained from both sides.

[[File:viewToBeChanged1.png]]
[[File:New1234.png]]

=Files to be Considered=
*reveiw_mapping_controller.rb

*teams_controller.rb

*team.rb

*views/assignments/edit/_review_strategy.html.erb

*views/grades/_reviews.html.erb

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-11T19:19:42Z

Rsinha2: /* Design */

=Introduction=
==Purpose==
'''Scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

==Scope==
The project provides instructor a functionality to make assignment reviews to be anonymous or non-anonymous. In addition, instructors have authority to create and assign review groups (students assigned same review group will review each others work) randomly.This scenario will be valid for individual assignments only. Also, anonymity is taken care from the perspective of reviewer as well as the reviewee. In case of non-anonymous groups, students may have the option to invite other students to join their group provided group size is not exceeding the maximum limit.

==Background==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Design=

'''Assignment Creation:'''

Providing a checkbox in "review strategy tab" to mark an assignment to have anonymous or non-anonymous reviews. By default, every assignment will be having anonymous reviews but an instructor can change it by unchecking the checkbox.

'''Group Formation:'''

The instructor has the authority to create and assign groups randomly. In this case, students can not drop the group they have been assigned and only an instructor can change their group if needed.
In case, a group has not been assigned by an instructor, students will have the functionality to invite other students to join their group. This functionality is analogous to the invite members to join their team.
Students in the same group can review work of their group members only.

For this, we will be creating a separate model for groups and will store all the group information into the corresponding database table. In order to follow the DRY principle, we will try to integrate the group code with the code written for teams.

'''Non Anonymous Reviews'''

In the case of non-anonymous reviews, students will be able to see the names of all the group members who have graded their individual work. In addition, students can also see whose work they are going to grade so that the non-anonymity is maintained from both sides.
[[File:New1234.png]]

=Files to be Considered=
*reveiw_mapping_controller.rb

*teams_controller.rb

*team.rb

*views/assignments/edit/_review_strategy.html.erb

*views/grades/_reviews.html.erb

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

File:New1234.png

2016-11-11T19:17:50Z

Rsinha2:

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T21:51:30Z

Rsinha2: /* Scope */

= '''E1698: Instructor/student control of anonymity + group-based reviewing''' =

=Introduction=
==Purpose==
'''The scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

==Scope==
The project provides instructor a functionality to make assignment reviews to be anonymous or non-anonymous. In addition, instructors have authority to create and assign review groups (students assigned same review group will review each others work) randomly.This scenario will be valid for individual assignments only. Also, anonymity is taken care from the perspective of reviewer as well as the reviewee. In case of non-anonymous groups, students may have the option to invite other students to join their group provided group size is not exceeding the maximum limit.

==Background==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.
==Documentation==

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Problem Statement=
'''The scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

=Design=

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T21:30:05Z

Rsinha2:

= '''E1698: Instructor/student control of anonymity + group-based reviewing''' =

=Introduction=
==Purpose==
'''The scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

==Scope==
==Background==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.
==Documentation==

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Problem Statement=
'''The scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

=Design=

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T21:22:41Z

Rsinha2: /* Design */

= '''E1698: Instructor/student control of anonymity + group-based reviewing''' =

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Problem Statement=
'''The scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

=Design=

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T20:28:13Z

Rsinha2: /* Problem Statement */

CSC/ECE 517 Fall 2016/oss E1656

2016-11-04T04:12:25Z

Rsinha2: /* UI Testing */

== E1656. Improve imports ==

This page provides a description of the Expertiza based OSS project.

__TOC__

==Introduction to Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework.

==Project Description==
===About Import===
In Expertiza, various kinds of data may be imported from [https://en.wikipedia.org/wiki/Comma-separated_values csv files], including users, participants in an assignemnt, topics and teams. When importing data, a corresponding csv file have to be composed. In a csv file, each new line represent a piece of datum and the different fields of a datum are separated by delimiters. But there are rough edges in the way these imports are done and certain other data that should be importable is not. This project focuses on implementing following tasks about data import functionality:

*When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
*Review assignments (“reviewer mappings”) should be able to be imported, but cannot be imported. See Issue 711
*It should be possible to import a list of users who have signed up for topics, but this feature does not yet exist. See Issue 153.
*For every kind of data to be imported, Expertiza currently specifies the ordering of fields. This isn’t very flexible; it may require the user (an instructor) to edit an existing CSV file. It would be better if, after importing the data, Expertiza showed the data together with dropdowns containing the default field headers. (This is similar to the way Excel shows data when it is imported from a CSV file.) Then the user could change the dropdowns to cause a different ordering of fields. See Issue 110.
*Create a way to export a list of teams that have signed up for topics, and who are waitlisted for topics, as well as participants in an assignment who have not signed up for topics. Choose the format, but keep it as consistent as possible with the other export formats. This would help the professor when students ask him for advice on finding teammates. Extra Issue

The following tasks were listed as a requirement, but after careful examination it was determined that these tasks were already implemented
*The simplest fix: If I try to import topics, the import page gives me this message: “The import process expects the following columns:” but it doesn’t say what the columns are (topic number, topic name, category, number of slots, category)! It used to be in the system; please revert the change to fix this bug. See Issue 719.
*When teams are imported in order to insert new members, the members are not inserted. See Issue 328.
*It should be possible to leave off the final fields in a line of a CSV file. These fields are often not specified anyway. For example, if a password isn’t specified when a new user is created, the system generates a password (see Issue 183). When importing topics, topic categories are rarely specified. But if the final field is blank, the import requires the CSV line to end with “, “ (comma and space). This should be fixed for all imports.

==About Versions Controller==
Git is a popular version control system, As a part of the project, We have made use of git for the purpose of version control. Our repository is a fork of the original Expertiza repository on which we have collaborated our work. And the project has been submitted through a pull request.

==Handle Duplicates (Issue329)==
====Current Implementation====

When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
The current implementation allows the user to handle duplicates, by the following techniques
*ignore the new team
*replace the existing team with the new team
*insert any new members into the existing team
*rename the new team and import
*rename the existing team and import

=====Functionality=====

The above functionalities make it easier to achieve the goal of handling duplicates while importing.

=====Drawbacks and Solutions=====

The above set of functionalities do not allow User to ever rename an existing team, rather force him rename his own team.
Thus the above requirement provides the necessary freedom to the User by providing him the option to rename an already existing team.

====New Implementation====

The option has been implemented using the update functionality that is already present in rails models, to update existing values of Active Records. To implement this feature we have also made use of the functionality for generating team names, that is already present within the Team model.

A code snippet is given below:
if handle_dups == "renameOldTeam" # rename: rename new team
if teamtype.is_a?(CourseTeam)
CourseTeam.update(team.id, :name => self.generate_team_name(Course.find(id).name))
return name
elsif teamtype.is_a?(AssignmentTeam)
AssignmentTeam.update(team.id, :name => self.generate_team_name(Assignment.find(id).name))
return name
end
end

'''Why has it been implemented the way it has been'''

The above implementation has been chosen as, it is the easiest way rails provides to update value of records using active records.

====UI Testing====
The Above feature has been tested from the UI using the both course Teams and Assignment Teams, where new teams were added with conflicting names and the rename existing team option was selected, which lead lead to the desired behavior, that is the team that was extant was renamed and new team was imported with the same name as that specified in the CSV file

1. Log in on Expertiza as instructor

2. Click Manage Assignments

3. Click Add Teams on any assignment listed

4. Click Import Teams at the bottom of the page

5. Choose the Rename an Existing Team Option and click import once the CSV has been chosen

==Fix Reviewer and Metareviewer Mappings (Issue711)==
====Current Implementation====

When an instructor tries to assign reviewers for an assignment, if the review strategy of the assignment is‘Instructor-Selected’, he could assign reviewers by directly importing the reviewer mappings. But now, when the instructor attempts to submit the import, the system will raise an argument error showing:

[[File:reviewfail.PNG]]

The import fails and, clearly, it's a bug in Expertiza.

====New Implementation====
To solve this problem, first refer to the view/review_mapping/_list_review_mappings.html.erb file and find out that the model to be imported is ReviewResponseMap. The import method in review_response_map.rb model file takes in 3 arguments which are row, _session and id. A code snippet of import_file_controller.rb (the import controller) is given below:
[[File:Reviewcode.PNG]]

Before we add the code in parentheses, the ReviewResponseMap model was not explicitly specified which case it belongs to and falls into the else statement where the import method takes in 4 arguments. That’s the reason of getting the “wrong number of argument” error. To resolve the problem, a "or params[:model] == 'ReviewResponseMap'" is inserted into the parentheses to make the import method of reviewer mappings takes in 3 arguments again and then we can correctly import the reviewer mappings. The recovery method for MetareviewResponseMap is exactly the same with this one by adding
"or params[:model] == 'MetareviewResponseMap'" statement into the parentheses.

====UI Testing====
1. Login as instructor. Click on ‘Manage Assignment’ to see all assignments in the database.

2. Among all the assignments, click the ‘Review strategy’ card in edit page and find out one assignment with 'Instructor-Selected' strategy (e.g. 'Design exercise'). Creating a new 'Instructor-Selected' assignment and add some participants to it is also applicable.

3. 'Assign reviewers' for this assignment and click on the 'Import reviewer mappings' on the bottom of the page.

4. Compose a csv file in the given format of 'Contributor, Reviewer1, Reviewer2, …, ReviewerN' and import the file. The ‘Contributor’ here is the name of a team in this assignment.

5. Go back to reviewer mappings page to check if the 'Reviewers of the Contributor' in the file are listed in the 'Reviewed By' section of the 'Contributors'.

==Import Sign Up Sheet (Issue153)==
====Current Implementation====

When a signup sheet is used in Expertiza, users are expected to sign up for topics. But, the instructor might've taken signups offline, e.g., by passing around a signup sheet in class. If the signup are not taken online by the students, the instructor has to impersonate all the students one by one and sign them up for a topic, which is tedious.

====New Implementation====
To implement this new issue, a model which is in charge of creating a sign_up and SignedUpTeam should be located first. In SignUpSheet model, methods are designed for the creation of a sign_up and SignedUpTeam using the data from data base and the new implementation should create them from an imported file. Hence, an ''import'' method is added to this model and a code snippet of it is shown as:

[[File:Signupcode.PNG]]

This new method imports new sign_up data in a format of "Topic identifier, User1, User2". Users here are the ones who signed up for the topic with a certain identifier (id). Some edge cases are also taken into consideration in this method to prevent importing a non-existing team in this assignment, a non-existing user or a user who is not a participant of this assignment.
Next, a link on the view page needs to be created to access this method. The instructor can view the sign up sheet of an assignment under the "topic" card of the "edit" section. An "Import sign up sheet" button is added beside the "Import topic" link

[[File:Button.PNG]]

and the corresponding code should be inserted in the "view/sign_up_sheet/_add_topics/html.erb" file.

[[File:View.PNG]]

After all of this, the new feature is successfully implemented and the instructor can directly import a large offline sign up sheet without tedious impersonating. The whole process of importing sign ups works exactly the same as student online sign ups. If the assignment does not have a topic yet, the 'Import sign up sheet' link will be invisible unless a topic is created or imported. If a imported user does not have a team, he will be automatically assigned a team and sign up for the topic. If users imported exceeds the limit a certain topic can hold, the leftmost users in the file (like the earliest signed up users) will have the topic and those right(later signed up) users will be in the wait list.

====UI Testing====
1. Login as instructor. Click on 'Manage Assignment’ to see all assignments in the database.

2. Click on 'edit', go to 'topic' card and find the "Import sign up sheet" link.

3. Compose a csv file in the given format of 'Topic identifier, User1, User2, …' and import the file. The ‘Topic identifier’ here is the 'topic#' in the sign up sheet.

4. Go back to sign up sheet page to check if the 'Users' in the file and their 'Teams' are listed under the 'Topic names' section.

==Export Assignment Participants (Extra Issue)==
===Current Implementation===
Current Implementation just allows users to Export the set of all Assignment Participants, of a given assignment. It doesn't allow any further filtering.

===Functionality===
The current functionality is very rigid and doesn't allow the user to know any more than the set of assignment Participants, which is also a major drawback

===New Implementation===
The new implementation allows user to export Assignment Participants in four ways.
* List of All Users mapped with team number and topic name who have signed up for an assignment topic
* List of All Users mapped with team number and topic name who are wait-listed for an assignment topic
* List of All Participants who haven't yet signed up for a topic and haven't formed teams yet
* List of All Participants

The functionality is present as a set of Radio buttons, which is checked by default to the fourth option that is to export all Participants. However that can be changed according to requirement.

The above has been implemented by creating a partial for the view to add the radio button. Further and If else bock has been used in the model, to identify the option selected and accordingly, on the required set of Rows are pushed to the csv file. To know whether a User has signed up or not for a topic, The SignedUpTeam model is used and to find if the team is wait listed or not, the is_waitlisted boolean value id used to determine if the team is wait listed or not.

A small Code snippet describing how one of these option was achieved is given below:
if options["participant_type"] == "signed"
Team.where(:parent_id=> parent_id).find_each do |team|
TeamsUser.where(:team_id=> team.id).find_each do |team_user|
user = User.find(team_user.user_id)
if SignedUpTeam.where( :team_id => team.id).where(:is_waitlisted => [false, nil," ", ""]).present?
assignemnt_team = SignedUpTeam.where( :team_id => team.id).where(:is_waitlisted => [false, nil," ", ""]).first
topic = SignUpTopic.find(assignemnt_team.topic_id)
csv << [
user.name,
user.fullname,
user.email,
user.role.name,
user.parent.name,
user.email_on_submission,
user.email_on_review,
user.email_on_review_of_review,
team.id,
topic.topic_name,
"handle"
]
end
end
end
'''Why has it been implemented the way it has been?'''

The implementation has been done in the above manner to maintain parity with the structure of export functions that have been implemented in the other models. Further Since, It is not going to be in any other manner within the model, there is no point of extracting methods, which would just affect performance due to added procedure call and return.

====UI Testing====
UI testing for the above was done by exporting Assignment Teams for a given assignment using all the above options individually and checking if the result actually matched what was expected. Example 'all' should export all the participants listed withing the assignment. 'Signed Up Team' gives all the participants who have signed up mapped to their teams and respective topics.

1. Sign in as Instructor

2. Click Manage -> Assignments

3. Click Add Participants for Final Project Assignment

4. Click Export Assignment participants at the bottom of the page.

5. Choose the appropriate option to export participants

==Ordering of Imported Fields (Issue 110)==
====Current Implementation====

Currently the order of the columns is preset and the user has to change the csv to match it.

=====Drawbacks and Solutions=====

This is inconvenient for the user to keep editing csv files. The solution iss to allow users chose the order of the columns as it appears in their csv file.

====New Implementation====
In the view we added the drop down fields based on the expected_fields

*Please choose the order of the columns here: 
<%@array_expected_values.each{|field|%>
<%=select_tag 'import_field_[field]', options_for_select(@array_expected_values.collect.with_index.to_a,field)%> 
<%}%>

In the import_file_controller.rb we made addition to the start method:

@array_expected_values = parse_line(@expected_fields,',',params)
b = ['...','MetareviewerN','ReviewerN','Team MemberN']
@array_expected_values.delete_if { |x| b.include?(x) }
if(@array_expected_values.include?("Team Member1"))
(3..4).each do |i|
@array_expected_values.push("Team Member#{i}")
end
elsif(@array_expected_values.include?("Reviewer1"))
(3..15).each do |i|
@array_expected_values.push("Reviewer#{i}")
end
elsif(@array_expected_values.include?("Metaeviewer1"))
(3..15).each do |i|
@array_expected_values.push("Metareviewer#{i}")
end

This allows expected_fields for the users and reviews to be unpacked as previously it was using wording such as "... userN"

Also in the import_file_controller.rb we added function that reorders the columns as they are expected by expertiza:

def reorder_row(row,params)
case params[:model]
when "AssignmentTeam"
expected_fields_variable_default = ['Team Name - optional', 'Team Member1','Team Member2', 'Team Member3', 'Team Member4']
when "User"
expected_fields_variable_default = [ 'username', 'full name (first[ middle] last)', 'e-mail address']
when "ReviewResponseMap"
expected_fields_variable_default = [ 'Contributor', 'Reviewer1', 'Reviewer2']
(3..15).each do |i|
expected_fields_variable_default.push("Reviewer#{i}")
end
when "MetaeviewResponseMap"
expected_fields_variable_default = [ 'Contributor', 'Reviewer', 'Metareviewer1','Metareviewer2']
(3..15).each do |i|
expected_fields_variable_default.push("Metareviewer#{i}")
end
when "SignUpTopic"
expected_fields_variable_default = [ 'Topic identifier', 'Topic name', 'Max choosers', 'Topic Category']
else
expected_fields_variable_default = ['Team Name - optional', 'Team Member1','Team Member2', 'Team Member3', 'Team Member4']
end
expected_fields_variable=[]
custom_order={}
return_row=[]
expected_fields_variable=expected_fields_variable_default.reject.with_index { |x,i| i > row.length-1 }
expected_fields_variable.each_with_index { |field, index|
custom_order[params["import_field_#{index}"]]=row[index]
}
expected_fields_variable.each_with_index { |field, index| return_row[index]=custom_order[field]}
return_row
end
====UI Testing====
To test this in the browser first need to be logged in as instructor. Then go to Manage -> Assignments -> Assignments tab. Then select to add teams to any assignment -> import teams. Here you would need to create a CSV file with the Team name and team members - separated by comma. The order of the column are arbitrary, just have to match them in the drop down fields provided.
For the team members there are maximum drop down fields, but you only need to fill out the relevant once. It will know to ignore irrelevant columns.

==Improvement Scope ==
The above Import as well as export functionalities that have been implemented in due course of the project have a scope for improvement. Imports and exports are functionalities that are used very often used to insert data as well to transfer data stored into the Models to external CSV files. Thus these features can be further tested using rspec tests as well as capybara and cucumber tests so as to make it fool proof. However these tests cannot be made such that they hamper the flexibility of the implementation to achieve a particular functionality.
Further We can also add options to handle duplicates as well as to filter out exports in other models as well, instead of the ones it is already present. Thus there is a scope of a lot more improvement to make Expertiza more user friendly.

CSC/ECE 517 Fall 2016/oss E1656

2016-11-04T01:25:12Z

Rsinha2: /* New Implementation */

== E1656. Improve imports ==

This page provides a description of the Expertiza based OSS project.

__TOC__

==Introduction to Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework.

==Project Description==
===About Import===
In Expertiza, various kinds of data may be imported from [https://en.wikipedia.org/wiki/Comma-separated_values csv files], including users, participants in an assignemnt, topics and teams. When importing data, a corresponding csv file have to be composed. In a csv file, each new line represent a piece of datum and the different fields of a datum are separated by delimiters. But there are rough edges in the way these imports are done and certain other data that should be importable is not. This project focuses on implementing following tasks about data import functionality:

*When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
*Review assignments (“reviewer mappings”) should be able to be imported, but cannot be imported. See Issue 711
*It should be possible to import a list of users who have signed up for topics, but this feature does not yet exist. See Issue 153.
*For every kind of data to be imported, Expertiza currently specifies the ordering of fields. This isn’t very flexible; it may require the user (an instructor) to edit an existing CSV file. It would be better if, after importing the data, Expertiza showed the data together with dropdowns containing the default field headers. (This is similar to the way Excel shows data when it is imported from a CSV file.) Then the user could change the dropdowns to cause a different ordering of fields. See Issue 110.
*Create a way to export a list of teams that have signed up for topics, and who are waitlisted for topics, as well as participants in an assignment who have not signed up for topics. Choose the format, but keep it as consistent as possible with the other export formats. This would help the professor when students ask him for advice on finding teammates. Extra Issue

The following tasks were listed as a requirement, but after careful examination it was determined that these tasks were already implemented
*The simplest fix: If I try to import topics, the import page gives me this message: “The import process expects the following columns:” but it doesn’t say what the columns are (topic number, topic name, category, number of slots, category)! It used to be in the system; please revert the change to fix this bug. See Issue 719.
*When teams are imported in order to insert new members, the members are not inserted. See Issue 328.
*It should be possible to leave off the final fields in a line of a CSV file. These fields are often not specified anyway. For example, if a password isn’t specified when a new user is created, the system generates a password (see Issue 183). When importing topics, topic categories are rarely specified. But if the final field is blank, the import requires the CSV line to end with “, “ (comma and space). This should be fixed for all imports.

==About Versions Controller==
Git is a popular version control system, As a part of the project, We have made use of git for the purpose of version control. Our repository is a fork of the original Expertiza repository on which we have collaborated our work. And the project has been submitted through a pull request.

==Handle Duplicates (Issue329)==
====Current Implementation====

When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
The current implementation allows the user to handle duplicates, by the following techniques
*ignore the new team
*replace the existing team with the new team
*insert any new members into the existing team
*rename the new team and import
*rename the existing team and import

=====Functionality=====

The above functionalities make it easier to achieve the goal of handling duplicates while importing.

=====Drawbacks and Solutions=====

The above set of functionalities do not allow User to ever rename an existing team, rather force him rename his own team.
Thus the above requirement provides the necessary freedom to the User by providing him the option to rename an already existing team.

====New Implementation====

The option has been implemented using the update functionality that is already present in rails models, to update existing values of Active Records. To implement this feature we have also made use of the functionality for generating team names, that is already present within the Team model.

A code snippet is given below:
if handle_dups == "renameOldTeam" # rename: rename new team
if teamtype.is_a?(CourseTeam)
CourseTeam.update(team.id, :name => self.generate_team_name(Course.find(id).name))
return name
elsif teamtype.is_a?(AssignmentTeam)
AssignmentTeam.update(team.id, :name => self.generate_team_name(Assignment.find(id).name))
return name
end
end

'''Why has it been implemented the way it has been'''

The above implementation has been chosen as, it is the easiest way rails provides to update value of records using active records.

====UI Testing====
The Above feature has been tested from the UI using the both course Teams and Assignment Teams, where new teams were added with conflicting names and the rename existing team option was selected, which lead lead to the desired behavior, that is the team that was extant was renamed and new team was imported with the same name as that specified in the CSV file

1. Log in on Expertiza as instructor

2. Click Manage Assignments

3. Click Add Teams on any assignment listed

4. Click Import Teams at the bottom of the page

5. Choose the Rename an Existing Team Option and click import once the CSV has been chosen

==Fix Reviewer and Metareviewer Mappings (Issue711)==
====Current Implementation====

When an instructor tries to assign reviewers for an assignment, if the review strategy of the assignment is‘Instructor-Selected’, he could assign reviewers by directly importing the reviewer mappings. But now, when the instructor attempts to submit the import, the system will raise an argument error showing:

[[File:reviewfail.PNG]]

The import fails and, clearly, it's a bug in Expertiza.

====New Implementation====
To solve this problem, first refer to the view/review_mapping/_list_review_mappings.html.erb file and find out that the model to be imported is ReviewResponseMap. The import method in review_response_map.rb model file takes in 3 arguments which are row, _session and id. A code snippet of import_file_controller.rb (the import controller) is given below:
[[File:Reviewcode.PNG]]

Before we add the code in parentheses, the ReviewResponseMap model was not explicitly specified which case it belongs to and falls into the else statement where the import method takes in 4 arguments. That’s the reason of getting the “wrong number of argument” error. To resolve the problem, a "or params[:model] == 'ReviewResponseMap'" is inserted into the parentheses to make the import method of reviewer mappings takes in 3 arguments again and then we can correctly import the reviewer mappings. The recovery method for MetareviewResponseMap is exactly the same with this one by adding
"or params[:model] == 'MetareviewResponseMap'" statement into the parentheses.

====UI Testing====
1. Login as instructor. Click on ‘Manage Assignment’ to see all assignments in the database.

2. Among all the assignments, click the ‘Review strategy’ card in edit page and find out one assignment with 'Instructor-Selected' strategy (e.g. 'Design exercise'). Creating a new 'Instructor-Selected' assignment and add some participants to it is also applicable.

3. 'Assign reviewers' for this assignment and click on the 'Import reviewer mappings' on the bottom of the page.

4. Compose a csv file in the given format of 'Contributor, Reviewer1, Reviewer2, …, ReviewerN' and import the file. The ‘Contributor’ here is the name of a team in this assignment.

5. Go back to reviewer mappings page to check if the 'Reviewers of the Contributor' in the file are listed in the 'Reviewed By' section of the 'Contributors'.

==Import Sign Up Sheet (Issue153)==
====Current Implementation====

When a signup sheet is used in Expertiza, users are expected to sign up for topics. But, the instructor might've taken signups offline, e.g., by passing around a signup sheet in class. If the signup are not taken online by the students, the instructor has to impersonate all the students one by one and sign them up for a topic, which is tedious.

====New Implementation====
To implement this new issue, a model which is in charge of creating a sign_up and SignedUpTeam should be located first. In SignUpSheet model, methods are designed for the creation of a sign_up and SignedUpTeam using the data from data base and the new implementation should create them from an imported file. Hence, an ''import'' method is added to this model and a code snippet of it is shown as:

[[File:Signupcode.PNG]]

This new method imports new sign_up data in a format of "Topic identifier, User1, User2". Users here are the ones who signed up for the topic with a certain identifier (id). Some edge cases are also taken into consideration in this method to prevent importing a non-existing team in this assignment, a non-existing user or a user who is not a participant of this assignment.
Next, a link on the view page needs to be created to access this method. The instructor can view the sign up sheet of an assignment under the "topic" card of the "edit" section. An "Import sign up sheet" button is added beside the "Import topic" link

[[File:Button.PNG]]

and the corresponding code should be inserted in the "view/sign_up_sheet/_add_topics/html.erb" file.

[[File:View.PNG]]

After all of this, the new feature is successfully implemented and the instructor can directly import a large offline sign up sheet without tedious impersonating. The whole process of importing sign ups works exactly the same as student online sign ups. If the assignment does not have a topic yet, the 'Import sign up sheet' link will be invisible unless a topic is created or imported. If a imported user does not have a team, he will be automatically assigned a team and sign up for the topic. If users imported exceeds the limit a certain topic can hold, the leftmost users in the file (like the earliest signed up users) will have the topic and those right(later signed up) users will be in the wait list.

====UI Testing====
1. Login as instructor. Click on 'Manage Assignment’ to see all assignments in the database.

2. Click on 'edit', go to 'topic' card and find the "Import sign up sheet" link.

3. Compose a csv file in the given format of 'Topic identifier, User1, User2, …' and import the file. The ‘Topic identifier’ here is the 'topic#' in the sign up sheet.

4. Go back to sign up sheet page to check if the 'Users' in the file and their 'Teams' are listed under the 'Topic names' section.

==Export Assignment Participants (Extra Issue)==
===Current Implementation===
Current Implementation just allows users to Export the set of all Assignment Participants, of a given assignment. It doesn't allow any further filtering.

===Functionality===
The current functionality is very rigid and doesn't allow the user to know any more than the set of assignment Participants, which is also a major drawback

===New Implementation===
The new implementation allows user to export Assignment Participants in four ways.
* List of All Users mapped with team number and topic name who have signed up for an assignment topic
* List of All Users mapped with team number and topic name who are wait-listed for an assignment topic
* List of All Participants who haven't yet signed up for a topic and haven't formed teams yet
* List of All Participants

The functionality is present as a set of Radio buttons, which is checked by default to the fourth option that is to export all Participants. However that can be changed according to requirement.

The above has been implemented by creating a partial for the view to add the radio button. Further and If else bock has been used in the model, to identify the option selected and accordingly, on the required set of Rows are pushed to the csv file. To know whether a User has signed up or not for a topic, The SignedUpTeam model is used and to find if the team is wait listed or not, the is_waitlisted boolean value id used to determine if the team is wait listed or not.

A small Code snippet describing how one of these option was achieved is given below:
if options["participant_type"] == "signed"
Team.where(:parent_id=> parent_id).find_each do |team|
TeamsUser.where(:team_id=> team.id).find_each do |team_user|
user = User.find(team_user.user_id)
if SignedUpTeam.where( :team_id => team.id).where(:is_waitlisted => [false, nil," ", ""]).present?
assignemnt_team = SignedUpTeam.where( :team_id => team.id).where(:is_waitlisted => [false, nil," ", ""]).first
topic = SignUpTopic.find(assignemnt_team.topic_id)
csv << [
user.name,
user.fullname,
user.email,
user.role.name,
user.parent.name,
user.email_on_submission,
user.email_on_review,
user.email_on_review_of_review,
team.id,
topic.topic_name,
"handle"
]
end
end
end
'''Why has it been implemented the way it has been?'''

The implementation has been done in the above manner to maintain parity with the structure of export functions that have been implemented in the other models. Further Since, It is not going to be in any other manner within the model, there is no point of extracting methods, which would just affect performance due to added procedure call and return.

====UI Testing====
UI testing for the above was done by exporting Assignment Teams for a given assignment using all the above options individually and checking if the result actually matched what was expected. Example 'all' should export all the participants listed withing the assignment. 'Signed Up Team' gives all the participants who have signed up mapped to their teams and respective topics.

1. Sign in as Instructor

2. Click Manage -> Assignments

3. Click Add Participants for any assignment

4. Click Export at the bottom of the page.

5. Choose the appropriate option to export participants

==Ordering of Imported Fields (Issue 110)==
====Current Implementation====

Currently the order of the columns is preset and the user has to change the csv to match it.

=====Drawbacks and Solutions=====

This is inconvenient for the user to keep editing csv files. The solution iss to allow users chose the order of the columns as it appears in their csv file.

====New Implementation====
In the view we added the drop down fields based on the expected_fields

*Please choose the order of the columns here: 
<%@array_expected_values.each{|field|%>
<%=select_tag 'import_field_[field]', options_for_select(@array_expected_values.collect.with_index.to_a,field)%> 
<%}%>

In the import_file_controller.rb we made addition to the start method:

@array_expected_values = parse_line(@expected_fields,',',params)
b = ['...','MetareviewerN','ReviewerN','Team MemberN']
@array_expected_values.delete_if { |x| b.include?(x) }
if(@array_expected_values.include?("Team Member1"))
(3..4).each do |i|
@array_expected_values.push("Team Member#{i}")
end
elsif(@array_expected_values.include?("Reviewer1"))
(3..15).each do |i|
@array_expected_values.push("Reviewer#{i}")
end
elsif(@array_expected_values.include?("Metaeviewer1"))
(3..15).each do |i|
@array_expected_values.push("Metareviewer#{i}")
end

This allows expected_fields for the users and reviews to be unpacked as previously it was using wording such as "... userN"

Also in the import_file_controller.rb we added function that reorders the columns as they are expected by expertiza:

def reorder_row(row,params)
case params[:model]
when "AssignmentTeam"
expected_fields_variable_default = ['Team Name - optional', 'Team Member1','Team Member2', 'Team Member3', 'Team Member4']
when "User"
expected_fields_variable_default = [ 'username', 'full name (first[ middle] last)', 'e-mail address']
when "ReviewResponseMap"
expected_fields_variable_default = [ 'Contributor', 'Reviewer1', 'Reviewer2']
(3..15).each do |i|
expected_fields_variable_default.push("Reviewer#{i}")
end
when "MetaeviewResponseMap"
expected_fields_variable_default = [ 'Contributor', 'Reviewer', 'Metareviewer1','Metareviewer2']
(3..15).each do |i|
expected_fields_variable_default.push("Metareviewer#{i}")
end
when "SignUpTopic"
expected_fields_variable_default = [ 'Topic identifier', 'Topic name', 'Max choosers', 'Topic Category']
else
expected_fields_variable_default = ['Team Name - optional', 'Team Member1','Team Member2', 'Team Member3', 'Team Member4']
end
expected_fields_variable=[]
custom_order={}
return_row=[]
expected_fields_variable=expected_fields_variable_default.reject.with_index { |x,i| i > row.length-1 }
expected_fields_variable.each_with_index { |field, index|
custom_order[params["import_field_#{index}"]]=row[index]
}
expected_fields_variable.each_with_index { |field, index| return_row[index]=custom_order[field]}
return_row
end
====UI Testing====
To test this in the browser first need to be logged in as instructor. Then go to Manage -> Assignments -> Assignments tab. Then select to add teams to any assignment -> import teams. Here you would need to create a CSV file with the Team name and team members - separated by comma. The order of the column are arbitrary, just have to match them in the drop down fields provided.
For the team members there are maximum drop down fields, but you only need to fill out the relevant once. It will know to ignore irrelevant columns.

==Improvement Scope ==
The above Import as well as export functionalities that have been implemented in due course of the project have a scope for improvement. Imports and exports are functionalities that are used very often used to insert data as well to transfer data stored into the Models to external CSV files. Thus these features can be further tested using rspec tests as well as capybara and cucumber tests so as to make it fool proof. However these tests cannot be made such that they hamper the flexibility of the implementation to achieve a particular functionality.
Further We can also add options to handle duplicates as well as to filter out exports in other models as well, instead of the ones it is already present. Thus there is a scope of a lot more improvement to make Expertiza more user friendly.

CSC/ECE 517 Fall 2016/oss E1656

2016-11-04T01:24:59Z

Rsinha2: /* New Implementation */

== E1656. Improve imports ==

This page provides a description of the Expertiza based OSS project.

__TOC__

==Introduction to Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework.

==Project Description==
===About Import===
In Expertiza, various kinds of data may be imported from [https://en.wikipedia.org/wiki/Comma-separated_values csv files], including users, participants in an assignemnt, topics and teams. When importing data, a corresponding csv file have to be composed. In a csv file, each new line represent a piece of datum and the different fields of a datum are separated by delimiters. But there are rough edges in the way these imports are done and certain other data that should be importable is not. This project focuses on implementing following tasks about data import functionality:

*When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
*Review assignments (“reviewer mappings”) should be able to be imported, but cannot be imported. See Issue 711
*It should be possible to import a list of users who have signed up for topics, but this feature does not yet exist. See Issue 153.
*For every kind of data to be imported, Expertiza currently specifies the ordering of fields. This isn’t very flexible; it may require the user (an instructor) to edit an existing CSV file. It would be better if, after importing the data, Expertiza showed the data together with dropdowns containing the default field headers. (This is similar to the way Excel shows data when it is imported from a CSV file.) Then the user could change the dropdowns to cause a different ordering of fields. See Issue 110.
*Create a way to export a list of teams that have signed up for topics, and who are waitlisted for topics, as well as participants in an assignment who have not signed up for topics. Choose the format, but keep it as consistent as possible with the other export formats. This would help the professor when students ask him for advice on finding teammates. Extra Issue

The following tasks were listed as a requirement, but after careful examination it was determined that these tasks were already implemented
*The simplest fix: If I try to import topics, the import page gives me this message: “The import process expects the following columns:” but it doesn’t say what the columns are (topic number, topic name, category, number of slots, category)! It used to be in the system; please revert the change to fix this bug. See Issue 719.
*When teams are imported in order to insert new members, the members are not inserted. See Issue 328.
*It should be possible to leave off the final fields in a line of a CSV file. These fields are often not specified anyway. For example, if a password isn’t specified when a new user is created, the system generates a password (see Issue 183). When importing topics, topic categories are rarely specified. But if the final field is blank, the import requires the CSV line to end with “, “ (comma and space). This should be fixed for all imports.

==About Versions Controller==
Git is a popular version control system, As a part of the project, We have made use of git for the purpose of version control. Our repository is a fork of the original Expertiza repository on which we have collaborated our work. And the project has been submitted through a pull request.

==Handle Duplicates (Issue329)==
====Current Implementation====

When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
The current implementation allows the user to handle duplicates, by the following techniques
*ignore the new team
*replace the existing team with the new team
*insert any new members into the existing team
*rename the new team and import
*rename the existing team and import

=====Functionality=====

The above functionalities make it easier to achieve the goal of handling duplicates while importing.

=====Drawbacks and Solutions=====

The above set of functionalities do not allow User to ever rename an existing team, rather force him rename his own team.
Thus the above requirement provides the necessary freedom to the User by providing him the option to rename an already existing team.

====New Implementation====

The option has been implemented using the update functionality that is already present in rails models, to update existing values of Active Records. To implement this feature we have also made use of the functionality for generating team names, that is already present within the Team model.

A code snippet is given below:
if handle_dups == "renameOldTeam" # rename: rename new team
if teamtype.is_a?(CourseTeam)
CourseTeam.update(team.id, :name => self.generate_team_name(Course.find(id).name))
return name
elsif teamtype.is_a?(AssignmentTeam)
AssignmentTeam.update(team.id, :name => self.generate_team_name(Assignment.find(id).name))
return name
end
end

'''Why has it been implemented the way it has been'''
The above implementation has been chosen as, it is the easiest way rails provides to update value of records using active records.

====UI Testing====
The Above feature has been tested from the UI using the both course Teams and Assignment Teams, where new teams were added with conflicting names and the rename existing team option was selected, which lead lead to the desired behavior, that is the team that was extant was renamed and new team was imported with the same name as that specified in the CSV file

1. Log in on Expertiza as instructor

2. Click Manage Assignments

3. Click Add Teams on any assignment listed

4. Click Import Teams at the bottom of the page

5. Choose the Rename an Existing Team Option and click import once the CSV has been chosen

==Fix Reviewer and Metareviewer Mappings (Issue711)==
====Current Implementation====

When an instructor tries to assign reviewers for an assignment, if the review strategy of the assignment is‘Instructor-Selected’, he could assign reviewers by directly importing the reviewer mappings. But now, when the instructor attempts to submit the import, the system will raise an argument error showing:

[[File:reviewfail.PNG]]

The import fails and, clearly, it's a bug in Expertiza.

====New Implementation====
To solve this problem, first refer to the view/review_mapping/_list_review_mappings.html.erb file and find out that the model to be imported is ReviewResponseMap. The import method in review_response_map.rb model file takes in 3 arguments which are row, _session and id. A code snippet of import_file_controller.rb (the import controller) is given below:
[[File:Reviewcode.PNG]]

Before we add the code in parentheses, the ReviewResponseMap model was not explicitly specified which case it belongs to and falls into the else statement where the import method takes in 4 arguments. That’s the reason of getting the “wrong number of argument” error. To resolve the problem, a "or params[:model] == 'ReviewResponseMap'" is inserted into the parentheses to make the import method of reviewer mappings takes in 3 arguments again and then we can correctly import the reviewer mappings. The recovery method for MetareviewResponseMap is exactly the same with this one by adding
"or params[:model] == 'MetareviewResponseMap'" statement into the parentheses.

====UI Testing====
1. Login as instructor. Click on ‘Manage Assignment’ to see all assignments in the database.

2. Among all the assignments, click the ‘Review strategy’ card in edit page and find out one assignment with 'Instructor-Selected' strategy (e.g. 'Design exercise'). Creating a new 'Instructor-Selected' assignment and add some participants to it is also applicable.

3. 'Assign reviewers' for this assignment and click on the 'Import reviewer mappings' on the bottom of the page.

4. Compose a csv file in the given format of 'Contributor, Reviewer1, Reviewer2, …, ReviewerN' and import the file. The ‘Contributor’ here is the name of a team in this assignment.

5. Go back to reviewer mappings page to check if the 'Reviewers of the Contributor' in the file are listed in the 'Reviewed By' section of the 'Contributors'.

==Import Sign Up Sheet (Issue153)==
====Current Implementation====

When a signup sheet is used in Expertiza, users are expected to sign up for topics. But, the instructor might've taken signups offline, e.g., by passing around a signup sheet in class. If the signup are not taken online by the students, the instructor has to impersonate all the students one by one and sign them up for a topic, which is tedious.

====New Implementation====
To implement this new issue, a model which is in charge of creating a sign_up and SignedUpTeam should be located first. In SignUpSheet model, methods are designed for the creation of a sign_up and SignedUpTeam using the data from data base and the new implementation should create them from an imported file. Hence, an ''import'' method is added to this model and a code snippet of it is shown as:

[[File:Signupcode.PNG]]

This new method imports new sign_up data in a format of "Topic identifier, User1, User2". Users here are the ones who signed up for the topic with a certain identifier (id). Some edge cases are also taken into consideration in this method to prevent importing a non-existing team in this assignment, a non-existing user or a user who is not a participant of this assignment.
Next, a link on the view page needs to be created to access this method. The instructor can view the sign up sheet of an assignment under the "topic" card of the "edit" section. An "Import sign up sheet" button is added beside the "Import topic" link

[[File:Button.PNG]]

and the corresponding code should be inserted in the "view/sign_up_sheet/_add_topics/html.erb" file.

[[File:View.PNG]]

After all of this, the new feature is successfully implemented and the instructor can directly import a large offline sign up sheet without tedious impersonating. The whole process of importing sign ups works exactly the same as student online sign ups. If the assignment does not have a topic yet, the 'Import sign up sheet' link will be invisible unless a topic is created or imported. If a imported user does not have a team, he will be automatically assigned a team and sign up for the topic. If users imported exceeds the limit a certain topic can hold, the leftmost users in the file (like the earliest signed up users) will have the topic and those right(later signed up) users will be in the wait list.

====UI Testing====
1. Login as instructor. Click on 'Manage Assignment’ to see all assignments in the database.

2. Click on 'edit', go to 'topic' card and find the "Import sign up sheet" link.

3. Compose a csv file in the given format of 'Topic identifier, User1, User2, …' and import the file. The ‘Topic identifier’ here is the 'topic#' in the sign up sheet.

4. Go back to sign up sheet page to check if the 'Users' in the file and their 'Teams' are listed under the 'Topic names' section.

==Export Assignment Participants (Extra Issue)==
===Current Implementation===
Current Implementation just allows users to Export the set of all Assignment Participants, of a given assignment. It doesn't allow any further filtering.

===Functionality===
The current functionality is very rigid and doesn't allow the user to know any more than the set of assignment Participants, which is also a major drawback

===New Implementation===
The new implementation allows user to export Assignment Participants in four ways.
* List of All Users mapped with team number and topic name who have signed up for an assignment topic
* List of All Users mapped with team number and topic name who are wait-listed for an assignment topic
* List of All Participants who haven't yet signed up for a topic and haven't formed teams yet
* List of All Participants

The functionality is present as a set of Radio buttons, which is checked by default to the fourth option that is to export all Participants. However that can be changed according to requirement.

The above has been implemented by creating a partial for the view to add the radio button. Further and If else bock has been used in the model, to identify the option selected and accordingly, on the required set of Rows are pushed to the csv file. To know whether a User has signed up or not for a topic, The SignedUpTeam model is used and to find if the team is wait listed or not, the is_waitlisted boolean value id used to determine if the team is wait listed or not.

A small Code snippet describing how one of these option was achieved is given below:
if options["participant_type"] == "signed"
Team.where(:parent_id=> parent_id).find_each do |team|
TeamsUser.where(:team_id=> team.id).find_each do |team_user|
user = User.find(team_user.user_id)
if SignedUpTeam.where( :team_id => team.id).where(:is_waitlisted => [false, nil," ", ""]).present?
assignemnt_team = SignedUpTeam.where( :team_id => team.id).where(:is_waitlisted => [false, nil," ", ""]).first
topic = SignUpTopic.find(assignemnt_team.topic_id)
csv << [
user.name,
user.fullname,
user.email,
user.role.name,
user.parent.name,
user.email_on_submission,
user.email_on_review,
user.email_on_review_of_review,
team.id,
topic.topic_name,
"handle"
]
end
end
end
'''Why has it been implemented the way it has been?'''

The implementation has been done in the above manner to maintain parity with the structure of export functions that have been implemented in the other models. Further Since, It is not going to be in any other manner within the model, there is no point of extracting methods, which would just affect performance due to added procedure call and return.

====UI Testing====
UI testing for the above was done by exporting Assignment Teams for a given assignment using all the above options individually and checking if the result actually matched what was expected. Example 'all' should export all the participants listed withing the assignment. 'Signed Up Team' gives all the participants who have signed up mapped to their teams and respective topics.

1. Sign in as Instructor

2. Click Manage -> Assignments

3. Click Add Participants for any assignment

4. Click Export at the bottom of the page.

5. Choose the appropriate option to export participants

==Ordering of Imported Fields (Issue 110)==
====Current Implementation====

Currently the order of the columns is preset and the user has to change the csv to match it.

=====Drawbacks and Solutions=====

This is inconvenient for the user to keep editing csv files. The solution iss to allow users chose the order of the columns as it appears in their csv file.

====New Implementation====
In the view we added the drop down fields based on the expected_fields

*Please choose the order of the columns here: 
<%@array_expected_values.each{|field|%>
<%=select_tag 'import_field_[field]', options_for_select(@array_expected_values.collect.with_index.to_a,field)%> 
<%}%>

In the import_file_controller.rb we made addition to the start method:

@array_expected_values = parse_line(@expected_fields,',',params)
b = ['...','MetareviewerN','ReviewerN','Team MemberN']
@array_expected_values.delete_if { |x| b.include?(x) }
if(@array_expected_values.include?("Team Member1"))
(3..4).each do |i|
@array_expected_values.push("Team Member#{i}")
end
elsif(@array_expected_values.include?("Reviewer1"))
(3..15).each do |i|
@array_expected_values.push("Reviewer#{i}")
end
elsif(@array_expected_values.include?("Metaeviewer1"))
(3..15).each do |i|
@array_expected_values.push("Metareviewer#{i}")
end

This allows expected_fields for the users and reviews to be unpacked as previously it was using wording such as "... userN"

Also in the import_file_controller.rb we added function that reorders the columns as they are expected by expertiza:

def reorder_row(row,params)
case params[:model]
when "AssignmentTeam"
expected_fields_variable_default = ['Team Name - optional', 'Team Member1','Team Member2', 'Team Member3', 'Team Member4']
when "User"
expected_fields_variable_default = [ 'username', 'full name (first[ middle] last)', 'e-mail address']
when "ReviewResponseMap"
expected_fields_variable_default = [ 'Contributor', 'Reviewer1', 'Reviewer2']
(3..15).each do |i|
expected_fields_variable_default.push("Reviewer#{i}")
end
when "MetaeviewResponseMap"
expected_fields_variable_default = [ 'Contributor', 'Reviewer', 'Metareviewer1','Metareviewer2']
(3..15).each do |i|
expected_fields_variable_default.push("Metareviewer#{i}")
end
when "SignUpTopic"
expected_fields_variable_default = [ 'Topic identifier', 'Topic name', 'Max choosers', 'Topic Category']
else
expected_fields_variable_default = ['Team Name - optional', 'Team Member1','Team Member2', 'Team Member3', 'Team Member4']
end
expected_fields_variable=[]
custom_order={}
return_row=[]
expected_fields_variable=expected_fields_variable_default.reject.with_index { |x,i| i > row.length-1 }
expected_fields_variable.each_with_index { |field, index|
custom_order[params["import_field_#{index}"]]=row[index]
}
expected_fields_variable.each_with_index { |field, index| return_row[index]=custom_order[field]}
return_row
end
====UI Testing====
To test this in the browser first need to be logged in as instructor. Then go to Manage -> Assignments -> Assignments tab. Then select to add teams to any assignment -> import teams. Here you would need to create a CSV file with the Team name and team members - separated by comma. The order of the column are arbitrary, just have to match them in the drop down fields provided.
For the team members there are maximum drop down fields, but you only need to fill out the relevant once. It will know to ignore irrelevant columns.

==Improvement Scope ==
The above Import as well as export functionalities that have been implemented in due course of the project have a scope for improvement. Imports and exports are functionalities that are used very often used to insert data as well to transfer data stored into the Models to external CSV files. Thus these features can be further tested using rspec tests as well as capybara and cucumber tests so as to make it fool proof. However these tests cannot be made such that they hamper the flexibility of the implementation to achieve a particular functionality.
Further We can also add options to handle duplicates as well as to filter out exports in other models as well, instead of the ones it is already present. Thus there is a scope of a lot more improvement to make Expertiza more user friendly.

CSC/ECE 517 Fall 2016/oss E1656

2016-11-04T01:23:09Z

Rsinha2: /* New Implementation */

== E1656. Improve imports ==

This page provides a description of the Expertiza based OSS project.

__TOC__

==Introduction to Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework.

==Project Description==
===About Import===
In Expertiza, various kinds of data may be imported from [https://en.wikipedia.org/wiki/Comma-separated_values csv files], including users, participants in an assignemnt, topics and teams. When importing data, a corresponding csv file have to be composed. In a csv file, each new line represent a piece of datum and the different fields of a datum are separated by delimiters. But there are rough edges in the way these imports are done and certain other data that should be importable is not. This project focuses on implementing following tasks about data import functionality:

*When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
*Review assignments (“reviewer mappings”) should be able to be imported, but cannot be imported. See Issue 711
*It should be possible to import a list of users who have signed up for topics, but this feature does not yet exist. See Issue 153.
*For every kind of data to be imported, Expertiza currently specifies the ordering of fields. This isn’t very flexible; it may require the user (an instructor) to edit an existing CSV file. It would be better if, after importing the data, Expertiza showed the data together with dropdowns containing the default field headers. (This is similar to the way Excel shows data when it is imported from a CSV file.) Then the user could change the dropdowns to cause a different ordering of fields. See Issue 110.
*Create a way to export a list of teams that have signed up for topics, and who are waitlisted for topics, as well as participants in an assignment who have not signed up for topics. Choose the format, but keep it as consistent as possible with the other export formats. This would help the professor when students ask him for advice on finding teammates. Extra Issue

The following tasks were listed as a requirement, but after careful examination it was determined that these tasks were already implemented
*The simplest fix: If I try to import topics, the import page gives me this message: “The import process expects the following columns:” but it doesn’t say what the columns are (topic number, topic name, category, number of slots, category)! It used to be in the system; please revert the change to fix this bug. See Issue 719.
*When teams are imported in order to insert new members, the members are not inserted. See Issue 328.
*It should be possible to leave off the final fields in a line of a CSV file. These fields are often not specified anyway. For example, if a password isn’t specified when a new user is created, the system generates a password (see Issue 183). When importing topics, topic categories are rarely specified. But if the final field is blank, the import requires the CSV line to end with “, “ (comma and space). This should be fixed for all imports.

==About Versions Controller==
Git is a popular version control system, As a part of the project, We have made use of git for the purpose of version control. Our repository is a fork of the original Expertiza repository on which we have collaborated our work. And the project has been submitted through a pull request.

==Handle Duplicates (Issue329)==
====Current Implementation====

When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
The current implementation allows the user to handle duplicates, by the following techniques
*ignore the new team
*replace the existing team with the new team
*insert any new members into the existing team
*rename the new team and import
*rename the existing team and import

=====Functionality=====

The above functionalities make it easier to achieve the goal of handling duplicates while importing.

=====Drawbacks and Solutions=====

The above set of functionalities do not allow User to ever rename an existing team, rather force him rename his own team.
Thus the above requirement provides the necessary freedom to the User by providing him the option to rename an already existing team.

====New Implementation====

The option has been implemented using the update functionality that is already present in rails models, to update existing values of Active Records. To implement this feature we have also made use of the functionality for generating team names, that is already present within the Team model.

A code snippet is given below:
if handle_dups == "renameOldTeam" # rename: rename new team
if teamtype.is_a?(CourseTeam)
CourseTeam.update(team.id, :name => self.generate_team_name(Course.find(id).name))
return name
elsif teamtype.is_a?(AssignmentTeam)
AssignmentTeam.update(team.id, :name => self.generate_team_name(Assignment.find(id).name))
return name
end
end

====UI Testing====
The Above feature has been tested from the UI using the both course Teams and Assignment Teams, where new teams were added with conflicting names and the rename existing team option was selected, which lead lead to the desired behavior, that is the team that was extant was renamed and new team was imported with the same name as that specified in the CSV file

1. Log in on Expertiza as instructor

2. Click Manage Assignments

3. Click Add Teams on any assignment listed

4. Click Import Teams at the bottom of the page

5. Choose the Rename an Existing Team Option and click import once the CSV has been chosen

==Fix Reviewer and Metareviewer Mappings (Issue711)==
====Current Implementation====

When an instructor tries to assign reviewers for an assignment, if the review strategy of the assignment is‘Instructor-Selected’, he could assign reviewers by directly importing the reviewer mappings. But now, when the instructor attempts to submit the import, the system will raise an argument error showing:

[[File:reviewfail.PNG]]

The import fails and, clearly, it's a bug in Expertiza.

====New Implementation====
To solve this problem, first refer to the view/review_mapping/_list_review_mappings.html.erb file and find out that the model to be imported is ReviewResponseMap. The import method in review_response_map.rb model file takes in 3 arguments which are row, _session and id. A code snippet of import_file_controller.rb (the import controller) is given below:
[[File:Reviewcode.PNG]]

Before we add the code in parentheses, the ReviewResponseMap model was not explicitly specified which case it belongs to and falls into the else statement where the import method takes in 4 arguments. That’s the reason of getting the “wrong number of argument” error. To resolve the problem, a "or params[:model] == 'ReviewResponseMap'" is inserted into the parentheses to make the import method of reviewer mappings takes in 3 arguments again and then we can correctly import the reviewer mappings. The recovery method for MetareviewResponseMap is exactly the same with this one by adding
"or params[:model] == 'MetareviewResponseMap'" statement into the parentheses.

====UI Testing====
1. Login as instructor. Click on ‘Manage Assignment’ to see all assignments in the database.

2. Among all the assignments, click the ‘Review strategy’ card in edit page and find out one assignment with 'Instructor-Selected' strategy (e.g. 'Design exercise'). Creating a new 'Instructor-Selected' assignment and add some participants to it is also applicable.

3. 'Assign reviewers' for this assignment and click on the 'Import reviewer mappings' on the bottom of the page.

4. Compose a csv file in the given format of 'Contributor, Reviewer1, Reviewer2, …, ReviewerN' and import the file. The ‘Contributor’ here is the name of a team in this assignment.

5. Go back to reviewer mappings page to check if the 'Reviewers of the Contributor' in the file are listed in the 'Reviewed By' section of the 'Contributors'.

==Import Sign Up Sheet (Issue153)==
====Current Implementation====

When a signup sheet is used in Expertiza, users are expected to sign up for topics. But, the instructor might've taken signups offline, e.g., by passing around a signup sheet in class. If the signup are not taken online by the students, the instructor has to impersonate all the students one by one and sign them up for a topic, which is tedious.

====New Implementation====
To implement this new issue, a model which is in charge of creating a sign_up and SignedUpTeam should be located first. In SignUpSheet model, methods are designed for the creation of a sign_up and SignedUpTeam using the data from data base and the new implementation should create them from an imported file. Hence, an ''import'' method is added to this model and a code snippet of it is shown as:

[[File:Signupcode.PNG]]

This new method imports new sign_up data in a format of "Topic identifier, User1, User2". Users here are the ones who signed up for the topic with a certain identifier (id). Some edge cases are also taken into consideration in this method to prevent importing a non-existing team in this assignment, a non-existing user or a user who is not a participant of this assignment.
Next, a link on the view page needs to be created to access this method. The instructor can view the sign up sheet of an assignment under the "topic" card of the "edit" section. An "Import sign up sheet" button is added beside the "Import topic" link

[[File:Button.PNG]]

and the corresponding code should be inserted in the "view/sign_up_sheet/_add_topics/html.erb" file.

[[File:View.PNG]]

After all of this, the new feature is successfully implemented and the instructor can directly import a large offline sign up sheet without tedious impersonating. The whole process of importing sign ups works exactly the same as student online sign ups. If the assignment does not have a topic yet, the 'Import sign up sheet' link will be invisible unless a topic is created or imported. If a imported user does not have a team, he will be automatically assigned a team and sign up for the topic. If users imported exceeds the limit a certain topic can hold, the leftmost users in the file (like the earliest signed up users) will have the topic and those right(later signed up) users will be in the wait list.

====UI Testing====
1. Login as instructor. Click on 'Manage Assignment’ to see all assignments in the database.

2. Click on 'edit', go to 'topic' card and find the "Import sign up sheet" link.

3. Compose a csv file in the given format of 'Topic identifier, User1, User2, …' and import the file. The ‘Topic identifier’ here is the 'topic#' in the sign up sheet.

4. Go back to sign up sheet page to check if the 'Users' in the file and their 'Teams' are listed under the 'Topic names' section.

==Export Assignment Participants (Extra Issue)==
===Current Implementation===
Current Implementation just allows users to Export the set of all Assignment Participants, of a given assignment. It doesn't allow any further filtering.

===Functionality===
The current functionality is very rigid and doesn't allow the user to know any more than the set of assignment Participants, which is also a major drawback

===New Implementation===
The new implementation allows user to export Assignment Participants in four ways.
* List of All Users mapped with team number and topic name who have signed up for an assignment topic
* List of All Users mapped with team number and topic name who are wait-listed for an assignment topic
* List of All Participants who haven't yet signed up for a topic and haven't formed teams yet
* List of All Participants

The functionality is present as a set of Radio buttons, which is checked by default to the fourth option that is to export all Participants. However that can be changed according to requirement.

The above has been implemented by creating a partial for the view to add the radio button. Further and If else bock has been used in the model, to identify the option selected and accordingly, on the required set of Rows are pushed to the csv file. To know whether a User has signed up or not for a topic, The SignedUpTeam model is used and to find if the team is wait listed or not, the is_waitlisted boolean value id used to determine if the team is wait listed or not.

A small Code snippet describing how one of these option was achieved is given below:
if options["participant_type"] == "signed"
Team.where(:parent_id=> parent_id).find_each do |team|
TeamsUser.where(:team_id=> team.id).find_each do |team_user|
user = User.find(team_user.user_id)
if SignedUpTeam.where( :team_id => team.id).where(:is_waitlisted => [false, nil," ", ""]).present?
assignemnt_team = SignedUpTeam.where( :team_id => team.id).where(:is_waitlisted => [false, nil," ", ""]).first
topic = SignUpTopic.find(assignemnt_team.topic_id)
csv << [
user.name,
user.fullname,
user.email,
user.role.name,
user.parent.name,
user.email_on_submission,
user.email_on_review,
user.email_on_review_of_review,
team.id,
topic.topic_name,
"handle"
]
end
end
end
'''Why has it been implemented the way it has been?'''

The implementation has been done in the above manner to maintain parity with the structure of export functions that have been implemented in the other models. Further Since, It is not going to be in any other manner within the model, there is no point of extracting methods, which would just affect performance due to added procedure call and return.

====UI Testing====
UI testing for the above was done by exporting Assignment Teams for a given assignment using all the above options individually and checking if the result actually matched what was expected. Example 'all' should export all the participants listed withing the assignment. 'Signed Up Team' gives all the participants who have signed up mapped to their teams and respective topics.

1. Sign in as Instructor

2. Click Manage -> Assignments

3. Click Add Participants for any assignment

4. Click Export at the bottom of the page.

5. Choose the appropriate option to export participants

==Ordering of Imported Fields (Issue 110)==
====Current Implementation====

Currently the order of the columns is preset and the user has to change the csv to match it.

=====Drawbacks and Solutions=====

This is inconvenient for the user to keep editing csv files. The solution iss to allow users chose the order of the columns as it appears in their csv file.

====New Implementation====
In the view we added the drop down fields based on the expected_fields

*Please choose the order of the columns here: 
<%@array_expected_values.each{|field|%>
<%=select_tag 'import_field_[field]', options_for_select(@array_expected_values.collect.with_index.to_a,field)%> 
<%}%>

In the import_file_controller.rb we made addition to the start method:

@array_expected_values = parse_line(@expected_fields,',',params)
b = ['...','MetareviewerN','ReviewerN','Team MemberN']
@array_expected_values.delete_if { |x| b.include?(x) }
if(@array_expected_values.include?("Team Member1"))
(3..4).each do |i|
@array_expected_values.push("Team Member#{i}")
end
elsif(@array_expected_values.include?("Reviewer1"))
(3..15).each do |i|
@array_expected_values.push("Reviewer#{i}")
end
elsif(@array_expected_values.include?("Metaeviewer1"))
(3..15).each do |i|
@array_expected_values.push("Metareviewer#{i}")
end

This allows expected_fields for the users and reviews to be unpacked as previously it was using wording such as "... userN"

Also in the import_file_controller.rb we added function that reorders the columns as they are expected by expertiza:

def reorder_row(row,params)
case params[:model]
when "AssignmentTeam"
expected_fields_variable_default = ['Team Name - optional', 'Team Member1','Team Member2', 'Team Member3', 'Team Member4']
when "User"
expected_fields_variable_default = [ 'username', 'full name (first[ middle] last)', 'e-mail address']
when "ReviewResponseMap"
expected_fields_variable_default = [ 'Contributor', 'Reviewer1', 'Reviewer2']
(3..15).each do |i|
expected_fields_variable_default.push("Reviewer#{i}")
end
when "MetaeviewResponseMap"
expected_fields_variable_default = [ 'Contributor', 'Reviewer', 'Metareviewer1','Metareviewer2']
(3..15).each do |i|
expected_fields_variable_default.push("Metareviewer#{i}")
end
when "SignUpTopic"
expected_fields_variable_default = [ 'Topic identifier', 'Topic name', 'Max choosers', 'Topic Category']
else
expected_fields_variable_default = ['Team Name - optional', 'Team Member1','Team Member2', 'Team Member3', 'Team Member4']
end
expected_fields_variable=[]
custom_order={}
return_row=[]
expected_fields_variable=expected_fields_variable_default.reject.with_index { |x,i| i > row.length-1 }
expected_fields_variable.each_with_index { |field, index|
custom_order[params["import_field_#{index}"]]=row[index]
}
expected_fields_variable.each_with_index { |field, index| return_row[index]=custom_order[field]}
return_row
end
====UI Testing====
To test this in the browser first need to be logged in as instructor. Then go to Manage -> Assignments -> Assignments tab. Then select to add teams to any assignment -> import teams. Here you would need to create a CSV file with the Team name and team members - separated by comma. The order of the column are arbitrary, just have to match them in the drop down fields provided.
For the team members there are maximum drop down fields, but you only need to fill out the relevant once. It will know to ignore irrelevant columns.

==Improvement Scope ==
The above Import as well as export functionalities that have been implemented in due course of the project have a scope for improvement. Imports and exports are functionalities that are used very often used to insert data as well to transfer data stored into the Models to external CSV files. Thus these features can be further tested using rspec tests as well as capybara and cucumber tests so as to make it fool proof. However these tests cannot be made such that they hamper the flexibility of the implementation to achieve a particular functionality.
Further We can also add options to handle duplicates as well as to filter out exports in other models as well, instead of the ones it is already present. Thus there is a scope of a lot more improvement to make Expertiza more user friendly.

CSC/ECE 517 Fall 2016/oss E1656

2016-10-29T23:27:32Z

Rsinha2: /* UI Testing */

== E1656. Improve imports ==

This page provides a description of the Expertiza based OSS project.

__TOC__

==Introduction to Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework.

==Project Description==
===About Import===
In Expertiza, various kinds of data may be imported from [https://en.wikipedia.org/wiki/Comma-separated_values csv files], including users, participants in an assignemnt, topics and teams. When importing data, a corresponding csv file have to be composed. In a csv file, each new line represent a piece of datum and the different fields of a datum are separated by delimiters. But there are rough edges in the way these imports are done and certain other data that should be importable is not. This project focuses on implementing following tasks about data import functionality:

*When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
*Review assignments (“reviewer mappings”) should be able to be imported, but cannot be imported. See Issue 711
*It should be possible to import a list of users who have signed up for topics, but this feature does not yet exist. See Issue 153.
*For every kind of data to be imported, Expertiza currently specifies the ordering of fields. This isn’t very flexible; it may require the user (an instructor) to edit an existing CSV file. It would be better if, after importing the data, Expertiza showed the data together with dropdowns containing the default field headers. (This is similar to the way Excel shows data when it is imported from a CSV file.) Then the user could change the dropdowns to cause a different ordering of fields. See Issue 110.
*Create a way to export a list of teams that have signed up for topics, and who are waitlisted for topics, as well as participants in an assignment who have not signed up for topics. Choose the format, but keep it as consistent as possible with the other export formats. This would help the professor when students ask him for advice on finding teammates. Extra Issue

The following tasks were listed as a requirement, but after careful examination it was determined that these tasks were already implemented
*The simplest fix: If I try to import topics, the import page gives me this message: “The import process expects the following columns:” but it doesn’t say what the columns are (topic number, topic name, category, number of slots, category)! It used to be in the system; please revert the change to fix this bug. See Issue 719.
*When teams are imported in order to insert new members, the members are not inserted. See Issue 328.
*It should be possible to leave off the final fields in a line of a CSV file. These fields are often not specified anyway. For example, if a password isn’t specified when a new user is created, the system generates a password (see Issue 183). When importing topics, topic categories are rarely specified. But if the final field is blank, the import requires the CSV line to end with “, “ (comma and space). This should be fixed for all imports.

==About Versions Controller==
Git is a popular version control system, As a part of the project, We have made use of git for the purpose of version control. Our repository is a fork of the original Expertiza repository on which we have collaborated our work. And the project has been submitted through a pull request.

==Handle Duplicates (Issue329)==
====Current Implementation====

When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
The current implementation allows the user to handle duplicates, by the following techniques
*ignore the new team
*replace the existing team with the new team
*insert any new members into the existing team
*rename the new team and import
*rename the existing team and import

=====Functionality=====

The above functionalities make it easier to achieve the goal of handling duplicates while importing.

=====Drawbacks and Solutions=====

The above set of functionalities do not allow User to ever rename an existing team, rather force him rename his own team.
Thus the above requirement provides the necessary freedom to the User by providing him the option to rename an already existing team.

====New Implementation====

The option has been implemented using the update functionality that is already present in rails models, to update existing values of Active Records. To implement this feature we have also made use of the functionality for generating team names, that is already present within the Team model.

A code snippet is given below:
if handle_dups == "renameOldTeam" # rename: rename new team
if teamtype.is_a?(CourseTeam)
CourseTeam.update(team.id, :name => self.generate_team_name(Course.find(id).name))
return name
elsif teamtype.is_a?(AssignmentTeam)
AssignmentTeam.update(team.id, :name => self.generate_team_name(Assignment.find(id).name))
return name
end
end

====UI Testing====
The Above feature has been tested from the UI using the both course Teams and Assignment Teams, where new teams were added with conflicting names and the rename existing team option was selected, which lead lead to the desired behavior, that is the team that was extant was renamed and new team was imported with the same name as that specified in the CSV file

1. Log in on Expertiza as instructor

2. Click Manage Assignments

3. Click Add Teams on any assignment listed

4. Click Import Teams at the bottom of the page

5. Choose the Rename an Existing Team Option and click import once the CSV has been chosen

==Fix Reviewer and Metareviewer Mappings (Issue711)==
====Current Implementation====

When an instructor tries to assign reviewers for an assignment, if the review strategy of the assignment is‘Instructor-Selected’, he could assign reviewers by directly importing the reviewer mappings. But now, when the instructor attempts to submit the import, the system will raise an argument error showing:

[[File:reviewfail.PNG]]

The import fails and, clearly, it's a bug in Expertiza.

====New Implementation====
To solve this problem, first refer to the view/review_mapping/_list_review_mappings.html.erb file and find out that the model to be imported is ReviewResponseMap. The import method in review_response_map.rb model file takes in 3 arguments which are row, _session and id. A code snippet of import_file_controller.rb (the import controller) is given below:
[[File:Reviewcode.PNG]]

Before we add the code in parentheses, the ReviewResponseMap model was not explicitly specified which case it belongs to and falls into the else statement where the import method takes in 4 arguments. That’s the reason of getting the “wrong number of argument” error. To resolve the problem, a "or params[:model] == 'ReviewResponseMap'" is inserted into the parentheses to make the import method of reviewer mappings takes in 3 arguments again and then we can correctly import the reviewer mappings. The recovery method for MetareviewResponseMap is exactly the same with this one by adding
"or params[:model] == 'MetareviewResponseMap'" statement into the parentheses.

====UI Testing====
1. Login as instructor. Click on ‘Manage Assignment’ to see all assignments in the database.

2. Among all the assignments, click the ‘Review strategy’ card in edit page and find out one assignment with 'Instructor-Selected' strategy (e.g. 'Design exercise'). Creating a new 'Instructor-Selected' assignment and add some participants to it is also applicable.

3. 'Assign reviewers' for this assignment and click on the 'Import reviewer mappings' on the bottom of the page.

4. Compose a csv file in the given format of 'Contributor, Reviewer1, Reviewer2, …, ReviewerN' and import the file. The ‘Contributor’ here is the name of a team in this assignment.

5. Go back to reviewer mappings page to check if the 'Reviewers of the Contributor' in the file are listed in the 'Reviewed By' section of the 'Contributors'.

==Import Sign Up Sheet (Issue153)==
====Current Implementation====

When a signup sheet is used in Expertiza, users are expected to sign up for topics. But, the instructor might've taken signups offline, e.g., by passing around a signup sheet in class. If the signup are not taken online by the students, the instructor has to impersonate all the students one by one and sign them up for a topic, which is tedious.

====New Implementation====
To implement this new issue, a model which is in charge of creating a sign_up and SignedUpTeam should be located first. In SignUpSheet model, methods are designed for the creation of a sign_up and SignedUpTeam using the data from data base and the new implementation should create them from an imported file. Hence, an ''import'' method is added to this model and a code snippet of it is shown as:

[[File:Signupcode.PNG]]

This new method imports new sign_up data in a format of "Topic identifier, User1, User2". Users here are the ones who signed up for the topic with a certain identifier (id). Some edge cases are also taken into consideration in this method to prevent importing a non-existing team in this assignment, a non-existing user or a user who is not a participant of this assignment.
Next, a link on the view page needs to be created to access this method. The instructor can view the sign up sheet of an assignment under the "topic" card of the "edit" section. An "Import sign up sheet" button is added beside the "Import topic" link

[[File:Button.PNG]]

and the corresponding code should be inserted in the "view/sign_up_sheet/_add_topics/html.erb" file.

[[File:View.PNG]]

After all of this, the new feature is successfully implemented and the instructor can directly import a large offline sign up sheet without tedious impersonating. The whole process of importing sign ups works exactly the same as student online sign ups. If the assignment does not have a topic yet, the 'Import sign up sheet' link will be invisible unless a topic is created or imported. If a imported user does not have a team, he will be automatically assigned a team and sign up for the topic. If users imported exceeds the limit a certain topic can hold, the leftmost users in the file (like the earliest signed up users) will have the topic and those right(later signed up) users will be in the wait list.

====UI Testing====
1. Login as instructor. Click on 'Manage Assignment’ to see all assignments in the database.

2. Click on 'edit', go to 'topic' card and find the "Import sign up sheet" link.

3. Compose a csv file in the given format of 'Topic identifier, User1, User2, …' and import the file. The ‘Topic identifier’ here is the 'topic#' in the sign up sheet.

4. Go back to sign up sheet page to check if the 'Users' in the file and their 'Teams' are listed under the 'Topic names' section.

==Export Assignment Participants (Extra Issue)==
===Current Implementation===
Current Implementation just allows users to Export the set of all Assignment Participants, of a given assignment. It doesn't allow any further filtering.

===Functionality===
The current functionality is very rigid and doesn't allow the user to know any more than the set of assignment Participants, which is also a major drawback

===New Implementation===
The new implementation allows user to export Assignment Participants in four ways.
* List of All Users mapped with team number and topic name who have signed up for an assignment topic
* List of All Users mapped with team number and topic name who are wait-listed for an assignment topic
* List of All Participants who haven't yet signed up for a topic and haven't formed teams yet
* List of All Participants

The functionality is present as a set of Radio buttons, which is checked by default to the fourth option that is to export all Participants. However that can be changed according to requirement.

The above has been implemented by creating a partial for the view to add the radio button. Further and If else bock has been used in the model, to identify the option selected and accordingly, on the required set of Rows are pushed to the csv file. To know whether a User has signed up or not for a topic, The SignedUpTeam model is used and to find if the team is wait listed or not, the is_waitlisted boolean value id used to determine if the team is wait listed or not.

A small Code snippet describing how one of these option was achieved is given below:
if options["participant_type"] == "signed"
Team.where(:parent_id=> parent_id).find_each do |team|
TeamsUser.where(:team_id=> team.id).find_each do |team_user|
user = User.find(team_user.user_id)
if SignedUpTeam.where( :team_id => team.id).where(:is_waitlisted => [false, nil," ", ""]).present?
assignemnt_team = SignedUpTeam.where( :team_id => team.id).where(:is_waitlisted => [false, nil," ", ""]).first
topic = SignUpTopic.find(assignemnt_team.topic_id)
csv << [
user.name,
user.fullname,
user.email,
user.role.name,
user.parent.name,
user.email_on_submission,
user.email_on_review,
user.email_on_review_of_review,
team.id,
topic.topic_name,
"handle"
]
end
end
end

====UI Testing====
UI testing for the above was done by exporting Assignment Teams for a given assignment using all the above options individually and checking if the result actually matched what was expected. Example 'all' should export all the participants listed withing the assignment. 'Signed Up Team' gives all the participants who have signed up mapped to their teams and respective topics.

1. Sign in as Instructor

2. Click Manage -> Assignments

3. Click Add Participants for any assignment

4. Click Export at the bottom of the page.

5. Choose the appropriate option to export participants

==Ordering of Imported Fields (Issue 110)==
====Current Implementation====

Currently the order of the columns is preset and the user has to change the csv to match it.

=====Drawbacks and Solutions=====

This is inconvenient for the user to keep editing csv files. The solution iss to allow users chose the order of the columns as it appears in their csv file.

====New Implementation====
In the view we added the drop down fields based on the expected_fields

*Please choose the order of the columns here: 
<%@array_expected_values.each{|field|%>
<%=select_tag 'import_field_[field]', options_for_select(@array_expected_values.collect.with_index.to_a,field)%> 
<%}%>

In the import_file_controller.rb we made addition to the start method:

@array_expected_values = parse_line(@expected_fields,',',params)
b = ['...','MetareviewerN','ReviewerN','Team MemberN']
@array_expected_values.delete_if { |x| b.include?(x) }
if(@array_expected_values.include?("Team Member1"))
(3..4).each do |i|
@array_expected_values.push("Team Member#{i}")
end
elsif(@array_expected_values.include?("Reviewer1"))
(3..15).each do |i|
@array_expected_values.push("Reviewer#{i}")
end
elsif(@array_expected_values.include?("Metaeviewer1"))
(3..15).each do |i|
@array_expected_values.push("Metareviewer#{i}")
end

This allows expected_fields for the users and reviews to be unpacked as previously it was using wording such as "... userN"

Also in the import_file_controller.rb we added function that reorders the columns as they are expected by expertiza:

def reorder_row(row,params)
case params[:model]
when "AssignmentTeam"
expected_fields_variable_default = ['Team Name - optional', 'Team Member1','Team Member2', 'Team Member3', 'Team Member4']
when "User"
expected_fields_variable_default = [ 'username', 'full name (first[ middle] last)', 'e-mail address']
when "ReviewResponseMap"
expected_fields_variable_default = [ 'Contributor', 'Reviewer1', 'Reviewer2']
(3..15).each do |i|
expected_fields_variable_default.push("Reviewer#{i}")
end
when "MetaeviewResponseMap"
expected_fields_variable_default = [ 'Contributor', 'Reviewer', 'Metareviewer1','Metareviewer2']
(3..15).each do |i|
expected_fields_variable_default.push("Metareviewer#{i}")
end
when "SignUpTopic"
expected_fields_variable_default = [ 'Topic identifier', 'Topic name', 'Max choosers', 'Topic Category']
else
expected_fields_variable_default = ['Team Name - optional', 'Team Member1','Team Member2', 'Team Member3', 'Team Member4']
end
expected_fields_variable=[]
custom_order={}
return_row=[]
expected_fields_variable=expected_fields_variable_default.reject.with_index { |x,i| i > row.length-1 }
expected_fields_variable.each_with_index { |field, index|
custom_order[params["import_field_#{index}"]]=row[index]
}
expected_fields_variable.each_with_index { |field, index| return_row[index]=custom_order[field]}
return_row
end

==Improvement Scope ==
The above Import as well as export functionalities that have been implemented in due course of the project have a scope for improvement. Imports and exports are functionalities that are used very often used to insert data as well to transfer data stored into the Models to external CSV files. Thus these features can be further tested using rspec tests as well as capybara and cucumber tests so as to make it fool proof. However these tests cannot be made such that they hamper the flexibility of the implementation to achieve a particular functionality.
Further We can also add options to handle duplicates as well as to filter out exports in other models as well, instead of the ones it is already present. Thus there is a scope of a lot more improvement to make Expertiza more user friendly.

CSC/ECE 517 Fall 2016/oss E1656

2016-10-29T23:24:48Z

Rsinha2: /* UI Testing */

== E1656. Improve imports ==

This page provides a description of the Expertiza based OSS project.

__TOC__

==Introduction to Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework.

==Project Description==
===About Import===
In Expertiza, various kinds of data may be imported from [https://en.wikipedia.org/wiki/Comma-separated_values csv files], including users, participants in an assignemnt, topics and teams. When importing data, a corresponding csv file have to be composed. In a csv file, each new line represent a piece of datum and the different fields of a datum are separated by delimiters. But there are rough edges in the way these imports are done and certain other data that should be importable is not. This project focuses on implementing following tasks about data import functionality:

*When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
*Review assignments (“reviewer mappings”) should be able to be imported, but cannot be imported. See Issue 711
*It should be possible to import a list of users who have signed up for topics, but this feature does not yet exist. See Issue 153.
*For every kind of data to be imported, Expertiza currently specifies the ordering of fields. This isn’t very flexible; it may require the user (an instructor) to edit an existing CSV file. It would be better if, after importing the data, Expertiza showed the data together with dropdowns containing the default field headers. (This is similar to the way Excel shows data when it is imported from a CSV file.) Then the user could change the dropdowns to cause a different ordering of fields. See Issue 110.
*Create a way to export a list of teams that have signed up for topics, and who are waitlisted for topics, as well as participants in an assignment who have not signed up for topics. Choose the format, but keep it as consistent as possible with the other export formats. This would help the professor when students ask him for advice on finding teammates. Extra Issue

The following tasks were listed as a requirement, but after careful examination it was determined that these tasks were already implemented
*The simplest fix: If I try to import topics, the import page gives me this message: “The import process expects the following columns:” but it doesn’t say what the columns are (topic number, topic name, category, number of slots, category)! It used to be in the system; please revert the change to fix this bug. See Issue 719.
*When teams are imported in order to insert new members, the members are not inserted. See Issue 328.
*It should be possible to leave off the final fields in a line of a CSV file. These fields are often not specified anyway. For example, if a password isn’t specified when a new user is created, the system generates a password (see Issue 183). When importing topics, topic categories are rarely specified. But if the final field is blank, the import requires the CSV line to end with “, “ (comma and space). This should be fixed for all imports.

==About Versions Controller==
Git is a popular version control system, As a part of the project, We have made use of git for the purpose of version control. Our repository is a fork of the original Expertiza repository on which we have collaborated our work. And the project has been submitted through a pull request.

==Handle Duplicates (Issue329)==
====Current Implementation====

When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
The current implementation allows the user to handle duplicates, by the following techniques
*ignore the new team
*replace the existing team with the new team
*insert any new members into the existing team
*rename the new team and import
*rename the existing team and import

=====Functionality=====

The above functionalities make it easier to achieve the goal of handling duplicates while importing.

=====Drawbacks and Solutions=====

The above set of functionalities do not allow User to ever rename an existing team, rather force him rename his own team.
Thus the above requirement provides the necessary freedom to the User by providing him the option to rename an already existing team.

====New Implementation====

The option has been implemented using the update functionality that is already present in rails models, to update existing values of Active Records. To implement this feature we have also made use of the functionality for generating team names, that is already present within the Team model.

A code snippet is given below:
if handle_dups == "renameOldTeam" # rename: rename new team
if teamtype.is_a?(CourseTeam)
CourseTeam.update(team.id, :name => self.generate_team_name(Course.find(id).name))
return name
elsif teamtype.is_a?(AssignmentTeam)
AssignmentTeam.update(team.id, :name => self.generate_team_name(Assignment.find(id).name))
return name
end
end

====UI Testing====
The Above feature has been tested from the UI using the both course Teams and Assignment Teams, where new teams were added with conflicting names and the rename existing team option was selected, which lead lead to the desired behavior, that is the team that was extant was renamed and new team was imported with the same name as that specified in the CSV file

1. Log in on Expertiza as instructor

2. Click Manage Assignments

3. Click Add Teams on any assignment listed

4. Click Import Teams at the bottom of the page

5. Choose the Rename an Existing Team Option and click import once the CSV has been chosen

==Fix Reviewer and Metareviewer Mappings (Issue711)==
====Current Implementation====

When an instructor tries to assign reviewers for an assignment, if the review strategy of the assignment is‘Instructor-Selected’, he could assign reviewers by directly importing the reviewer mappings. But now, when the instructor attempts to submit the import, the system will raise an argument error showing:

[[File:reviewfail.PNG]]

The import fails and, clearly, it's a bug in Expertiza.

====New Implementation====
To solve this problem, first refer to the view/review_mapping/_list_review_mappings.html.erb file and find out that the model to be imported is ReviewResponseMap. The import method in review_response_map.rb model file takes in 3 arguments which are row, _session and id. A code snippet of import_file_controller.rb (the import controller) is given below:
[[File:Reviewcode.PNG]]

Before we add the code in parentheses, the ReviewResponseMap model was not explicitly specified which case it belongs to and falls into the else statement where the import method takes in 4 arguments. That’s the reason of getting the “wrong number of argument” error. To resolve the problem, a "or params[:model] == 'ReviewResponseMap'" is inserted into the parentheses to make the import method of reviewer mappings takes in 3 arguments again and then we can correctly import the reviewer mappings. The recovery method for MetareviewResponseMap is exactly the same with this one by adding
"or params[:model] == 'MetareviewResponseMap'" statement into the parentheses.

====UI Testing====
1. Login as instructor. Click on ‘Manage Assignment’ to see all assignments in the database.

2. Among all the assignments, click the ‘Review strategy’ card in edit page and find out one assignment with 'Instructor-Selected' strategy (e.g. 'Design exercise'). Creating a new 'Instructor-Selected' assignment and add some participants to it is also applicable.

3. 'Assign reviewers' for this assignment and click on the 'Import reviewer mappings' on the bottom of the page.

4. Compose a csv file in the given format of 'Contributor, Reviewer1, Reviewer2, …, ReviewerN' and import the file. The ‘Contributor’ here is the name of a team in this assignment.

5. Go back to reviewer mappings page to check if the 'Reviewers of the Contributor' in the file are listed in the 'Reviewed By' section of the 'Contributors'.

==Import Sign Up Sheet (Issue153)==
====Current Implementation====

When a signup sheet is used in Expertiza, users are expected to sign up for topics. But, the instructor might've taken signups offline, e.g., by passing around a signup sheet in class. If the signup are not taken online by the students, the instructor has to impersonate all the students one by one and sign them up for a topic, which is tedious.

====New Implementation====
To implement this new issue, a model which is in charge of creating a sign_up and SignedUpTeam should be located first. In SignUpSheet model, methods are designed for the creation of a sign_up and SignedUpTeam using the data from data base and the new implementation should create them from an imported file. Hence, an ''import'' method is added to this model and a code snippet of it is shown as:

[[File:Signupcode.PNG]]

This new method imports new sign_up data in a format of "Topic identifier, User1, User2". Users here are the ones who signed up for the topic with a certain identifier (id). Some edge cases are also taken into consideration in this method to prevent importing a non-existing team in this assignment, a non-existing user or a user who is not a participant of this assignment.
Next, a link on the view page needs to be created to access this method. The instructor can view the sign up sheet of an assignment under the "topic" card of the "edit" section. An "Import sign up sheet" button is added beside the "Import topic" link

[[File:Button.PNG]]

and the corresponding code should be inserted in the "view/sign_up_sheet/_add_topics/html.erb" file.

[[File:View.PNG]]

After all of this, the new feature is successfully implemented and the instructor can directly import a large offline sign up sheet without tedious impersonating. The whole process of importing sign ups works exactly the same as student online sign ups. If the assignment does not have a topic yet, the 'Import sign up sheet' link will be invisible unless a topic is created or imported. If a imported user does not have a team, he will be automatically assigned a team and sign up for the topic. If users imported exceeds the limit a certain topic can hold, the leftmost users in the file (like the earliest signed up users) will have the topic and those right(later signed up) users will be in the wait list.

====UI Testing====
1. Login as instructor. Click on 'Manage Assignment’ to see all assignments in the database.

2. Click on 'edit', go to 'topic' card and find the "Import sign up sheet" link.

3. Compose a csv file in the given format of 'Topic identifier, User1, User2, …' and import the file. The ‘Topic identifier’ here is the 'topic#' in the sign up sheet.

4. Go back to sign up sheet page to check if the 'Users' in the file and their 'Teams' are listed under the 'Topic names' section.

==Export Assignment Participants (Extra Issue)==
===Current Implementation===
Current Implementation just allows users to Export the set of all Assignment Participants, of a given assignment. It doesn't allow any further filtering.

===Functionality===
The current functionality is very rigid and doesn't allow the user to know any more than the set of assignment Participants, which is also a major drawback

===New Implementation===
The new implementation allows user to export Assignment Participants in four ways.
* List of All Users mapped with team number and topic name who have signed up for an assignment topic
* List of All Users mapped with team number and topic name who are wait-listed for an assignment topic
* List of All Participants who haven't yet signed up for a topic and haven't formed teams yet
* List of All Participants

The functionality is present as a set of Radio buttons, which is checked by default to the fourth option that is to export all Participants. However that can be changed according to requirement.

The above has been implemented by creating a partial for the view to add the radio button. Further and If else bock has been used in the model, to identify the option selected and accordingly, on the required set of Rows are pushed to the csv file. To know whether a User has signed up or not for a topic, The SignedUpTeam model is used and to find if the team is wait listed or not, the is_waitlisted boolean value id used to determine if the team is wait listed or not.

A small Code snippet describing how one of these option was achieved is given below:
if options["participant_type"] == "signed"
Team.where(:parent_id=> parent_id).find_each do |team|
TeamsUser.where(:team_id=> team.id).find_each do |team_user|
user = User.find(team_user.user_id)
if SignedUpTeam.where( :team_id => team.id).where(:is_waitlisted => [false, nil," ", ""]).present?
assignemnt_team = SignedUpTeam.where( :team_id => team.id).where(:is_waitlisted => [false, nil," ", ""]).first
topic = SignUpTopic.find(assignemnt_team.topic_id)
csv << [
user.name,
user.fullname,
user.email,
user.role.name,
user.parent.name,
user.email_on_submission,
user.email_on_review,
user.email_on_review_of_review,
team.id,
topic.topic_name,
"handle"
]
end
end
end

====UI Testing====
UI testing for the above was done by exporting Assignment Teams for a given assignment using all the above options individually and checking if the result actually matched what was expected. Example 'all' should export all the participants listed withing the assignment. 'Signed Up Team' gives all the participants who have signed up mapped to their teams and respective topics.
If you are signed in as Instructor:
Feature can be tested by clicking on add participants button in manage assignments and then clicking on export course participants at the bottom of the page. And then following the applicable option for testing the respective features described above.

==Ordering of Imported Fields (Issue 110)==
====Current Implementation====

Currently the order of the columns is preset and the user has to change the csv to match it.

=====Drawbacks and Solutions=====

This is inconvenient for the user to keep editing csv files. The solution iss to allow users chose the order of the columns as it appears in their csv file.

====New Implementation====
In the view we added the drop down fields based on the expected_fields

*Please choose the order of the columns here: 
<%@array_expected_values.each{|field|%>
<%=select_tag 'import_field_[field]', options_for_select(@array_expected_values.collect.with_index.to_a,field)%> 
<%}%>

In the import_file_controller.rb we made addition to the start method:

@array_expected_values = parse_line(@expected_fields,',',params)
b = ['...','MetareviewerN','ReviewerN','Team MemberN']
@array_expected_values.delete_if { |x| b.include?(x) }
if(@array_expected_values.include?("Team Member1"))
(3..4).each do |i|
@array_expected_values.push("Team Member#{i}")
end
elsif(@array_expected_values.include?("Reviewer1"))
(3..15).each do |i|
@array_expected_values.push("Reviewer#{i}")
end
elsif(@array_expected_values.include?("Metaeviewer1"))
(3..15).each do |i|
@array_expected_values.push("Metareviewer#{i}")
end

This allows expected_fields for the users and reviews to be unpacked as previously it was using wording such as "... userN"

Also in the import_file_controller.rb we added function that reorders the columns as they are expected by expertiza:

def reorder_row(row,params)
case params[:model]
when "AssignmentTeam"
expected_fields_variable_default = ['Team Name - optional', 'Team Member1','Team Member2', 'Team Member3', 'Team Member4']
when "User"
expected_fields_variable_default = [ 'username', 'full name (first[ middle] last)', 'e-mail address']
when "ReviewResponseMap"
expected_fields_variable_default = [ 'Contributor', 'Reviewer1', 'Reviewer2']
(3..15).each do |i|
expected_fields_variable_default.push("Reviewer#{i}")
end
when "MetaeviewResponseMap"
expected_fields_variable_default = [ 'Contributor', 'Reviewer', 'Metareviewer1','Metareviewer2']
(3..15).each do |i|
expected_fields_variable_default.push("Metareviewer#{i}")
end
when "SignUpTopic"
expected_fields_variable_default = [ 'Topic identifier', 'Topic name', 'Max choosers', 'Topic Category']
else
expected_fields_variable_default = ['Team Name - optional', 'Team Member1','Team Member2', 'Team Member3', 'Team Member4']
end
expected_fields_variable=[]
custom_order={}
return_row=[]
expected_fields_variable=expected_fields_variable_default.reject.with_index { |x,i| i > row.length-1 }
expected_fields_variable.each_with_index { |field, index|
custom_order[params["import_field_#{index}"]]=row[index]
}
expected_fields_variable.each_with_index { |field, index| return_row[index]=custom_order[field]}
return_row
end

==Improvement Scope ==
The above Import as well as export functionalities that have been implemented in due course of the project have a scope for improvement. Imports and exports are functionalities that are used very often used to insert data as well to transfer data stored into the Models to external CSV files. Thus these features can be further tested using rspec tests as well as capybara and cucumber tests so as to make it fool proof. However these tests cannot be made such that they hamper the flexibility of the implementation to achieve a particular functionality.
Further We can also add options to handle duplicates as well as to filter out exports in other models as well, instead of the ones it is already present. Thus there is a scope of a lot more improvement to make Expertiza more user friendly.

CSC/ECE 517 Fall 2016/oss E1656

2016-10-29T23:24:09Z

Rsinha2: /* UI Testing */

== E1656. Improve imports ==

This page provides a description of the Expertiza based OSS project.

__TOC__

==Introduction to Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework.

==Project Description==
===About Import===
In Expertiza, various kinds of data may be imported from [https://en.wikipedia.org/wiki/Comma-separated_values csv files], including users, participants in an assignemnt, topics and teams. When importing data, a corresponding csv file have to be composed. In a csv file, each new line represent a piece of datum and the different fields of a datum are separated by delimiters. But there are rough edges in the way these imports are done and certain other data that should be importable is not. This project focuses on implementing following tasks about data import functionality:

*When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
*Review assignments (“reviewer mappings”) should be able to be imported, but cannot be imported. See Issue 711
*It should be possible to import a list of users who have signed up for topics, but this feature does not yet exist. See Issue 153.
*For every kind of data to be imported, Expertiza currently specifies the ordering of fields. This isn’t very flexible; it may require the user (an instructor) to edit an existing CSV file. It would be better if, after importing the data, Expertiza showed the data together with dropdowns containing the default field headers. (This is similar to the way Excel shows data when it is imported from a CSV file.) Then the user could change the dropdowns to cause a different ordering of fields. See Issue 110.
*Create a way to export a list of teams that have signed up for topics, and who are waitlisted for topics, as well as participants in an assignment who have not signed up for topics. Choose the format, but keep it as consistent as possible with the other export formats. This would help the professor when students ask him for advice on finding teammates. Extra Issue

The following tasks were listed as a requirement, but after careful examination it was determined that these tasks were already implemented
*The simplest fix: If I try to import topics, the import page gives me this message: “The import process expects the following columns:” but it doesn’t say what the columns are (topic number, topic name, category, number of slots, category)! It used to be in the system; please revert the change to fix this bug. See Issue 719.
*When teams are imported in order to insert new members, the members are not inserted. See Issue 328.
*It should be possible to leave off the final fields in a line of a CSV file. These fields are often not specified anyway. For example, if a password isn’t specified when a new user is created, the system generates a password (see Issue 183). When importing topics, topic categories are rarely specified. But if the final field is blank, the import requires the CSV line to end with “, “ (comma and space). This should be fixed for all imports.

==About Versions Controller==
Git is a popular version control system, As a part of the project, We have made use of git for the purpose of version control. Our repository is a fork of the original Expertiza repository on which we have collaborated our work. And the project has been submitted through a pull request.

==Handle Duplicates (Issue329)==
====Current Implementation====

When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
The current implementation allows the user to handle duplicates, by the following techniques
*ignore the new team
*replace the existing team with the new team
*insert any new members into the existing team
*rename the new team and import
*rename the existing team and import

=====Functionality=====

The above functionalities make it easier to achieve the goal of handling duplicates while importing.

=====Drawbacks and Solutions=====

The above set of functionalities do not allow User to ever rename an existing team, rather force him rename his own team.
Thus the above requirement provides the necessary freedom to the User by providing him the option to rename an already existing team.

====New Implementation====

The option has been implemented using the update functionality that is already present in rails models, to update existing values of Active Records. To implement this feature we have also made use of the functionality for generating team names, that is already present within the Team model.

A code snippet is given below:
if handle_dups == "renameOldTeam" # rename: rename new team
if teamtype.is_a?(CourseTeam)
CourseTeam.update(team.id, :name => self.generate_team_name(Course.find(id).name))
return name
elsif teamtype.is_a?(AssignmentTeam)
AssignmentTeam.update(team.id, :name => self.generate_team_name(Assignment.find(id).name))
return name
end
end

====UI Testing====
The Above feature has been tested from the UI using the both course Teams and Assignment Teams, where new teams were added with conflicting names and the rename existing team option was selected, which lead lead to the desired behavior, that is the team that was extant was renamed and new team was imported with the same name as that specified in the CSV file

1. Log in on Expertiza as instructor
2. Click Manage Assignments
3. Click Add Teams on any assignment listed
4. Click Import Teams at the bottom of the page
5. Choose the Rename an Existing Team Option and click import once the CSV has been chosen

==Fix Reviewer and Metareviewer Mappings (Issue711)==
====Current Implementation====

When an instructor tries to assign reviewers for an assignment, if the review strategy of the assignment is‘Instructor-Selected’, he could assign reviewers by directly importing the reviewer mappings. But now, when the instructor attempts to submit the import, the system will raise an argument error showing:

[[File:reviewfail.PNG]]

The import fails and, clearly, it's a bug in Expertiza.

====New Implementation====
To solve this problem, first refer to the view/review_mapping/_list_review_mappings.html.erb file and find out that the model to be imported is ReviewResponseMap. The import method in review_response_map.rb model file takes in 3 arguments which are row, _session and id. A code snippet of import_file_controller.rb (the import controller) is given below:
[[File:Reviewcode.PNG]]

Before we add the code in parentheses, the ReviewResponseMap model was not explicitly specified which case it belongs to and falls into the else statement where the import method takes in 4 arguments. That’s the reason of getting the “wrong number of argument” error. To resolve the problem, a "or params[:model] == 'ReviewResponseMap'" is inserted into the parentheses to make the import method of reviewer mappings takes in 3 arguments again and then we can correctly import the reviewer mappings. The recovery method for MetareviewResponseMap is exactly the same with this one by adding
"or params[:model] == 'MetareviewResponseMap'" statement into the parentheses.

====UI Testing====
1. Login as instructor. Click on ‘Manage Assignment’ to see all assignments in the database.

2. Among all the assignments, click the ‘Review strategy’ card in edit page and find out one assignment with 'Instructor-Selected' strategy (e.g. 'Design exercise'). Creating a new 'Instructor-Selected' assignment and add some participants to it is also applicable.

3. 'Assign reviewers' for this assignment and click on the 'Import reviewer mappings' on the bottom of the page.

4. Compose a csv file in the given format of 'Contributor, Reviewer1, Reviewer2, …, ReviewerN' and import the file. The ‘Contributor’ here is the name of a team in this assignment.

5. Go back to reviewer mappings page to check if the 'Reviewers of the Contributor' in the file are listed in the 'Reviewed By' section of the 'Contributors'.

==Import Sign Up Sheet (Issue153)==
====Current Implementation====

When a signup sheet is used in Expertiza, users are expected to sign up for topics. But, the instructor might've taken signups offline, e.g., by passing around a signup sheet in class. If the signup are not taken online by the students, the instructor has to impersonate all the students one by one and sign them up for a topic, which is tedious.

====New Implementation====
To implement this new issue, a model which is in charge of creating a sign_up and SignedUpTeam should be located first. In SignUpSheet model, methods are designed for the creation of a sign_up and SignedUpTeam using the data from data base and the new implementation should create them from an imported file. Hence, an ''import'' method is added to this model and a code snippet of it is shown as:

[[File:Signupcode.PNG]]

This new method imports new sign_up data in a format of "Topic identifier, User1, User2". Users here are the ones who signed up for the topic with a certain identifier (id). Some edge cases are also taken into consideration in this method to prevent importing a non-existing team in this assignment, a non-existing user or a user who is not a participant of this assignment.
Next, a link on the view page needs to be created to access this method. The instructor can view the sign up sheet of an assignment under the "topic" card of the "edit" section. An "Import sign up sheet" button is added beside the "Import topic" link

[[File:Button.PNG]]

and the corresponding code should be inserted in the "view/sign_up_sheet/_add_topics/html.erb" file.

[[File:View.PNG]]

After all of this, the new feature is successfully implemented and the instructor can directly import a large offline sign up sheet without tedious impersonating. The whole process of importing sign ups works exactly the same as student online sign ups. If the assignment does not have a topic yet, the 'Import sign up sheet' link will be invisible unless a topic is created or imported. If a imported user does not have a team, he will be automatically assigned a team and sign up for the topic. If users imported exceeds the limit a certain topic can hold, the leftmost users in the file (like the earliest signed up users) will have the topic and those right(later signed up) users will be in the wait list.

====UI Testing====
1. Login as instructor. Click on 'Manage Assignment’ to see all assignments in the database.

2. Click on 'edit', go to 'topic' card and find the "Import sign up sheet" link.

3. Compose a csv file in the given format of 'Topic identifier, User1, User2, …' and import the file. The ‘Topic identifier’ here is the 'topic#' in the sign up sheet.

4. Go back to sign up sheet page to check if the 'Users' in the file and their 'Teams' are listed under the 'Topic names' section.

==Export Assignment Participants (Extra Issue)==
===Current Implementation===
Current Implementation just allows users to Export the set of all Assignment Participants, of a given assignment. It doesn't allow any further filtering.

===Functionality===
The current functionality is very rigid and doesn't allow the user to know any more than the set of assignment Participants, which is also a major drawback

===New Implementation===
The new implementation allows user to export Assignment Participants in four ways.
* List of All Users mapped with team number and topic name who have signed up for an assignment topic
* List of All Users mapped with team number and topic name who are wait-listed for an assignment topic
* List of All Participants who haven't yet signed up for a topic and haven't formed teams yet
* List of All Participants

The functionality is present as a set of Radio buttons, which is checked by default to the fourth option that is to export all Participants. However that can be changed according to requirement.

The above has been implemented by creating a partial for the view to add the radio button. Further and If else bock has been used in the model, to identify the option selected and accordingly, on the required set of Rows are pushed to the csv file. To know whether a User has signed up or not for a topic, The SignedUpTeam model is used and to find if the team is wait listed or not, the is_waitlisted boolean value id used to determine if the team is wait listed or not.

A small Code snippet describing how one of these option was achieved is given below:
if options["participant_type"] == "signed"
Team.where(:parent_id=> parent_id).find_each do |team|
TeamsUser.where(:team_id=> team.id).find_each do |team_user|
user = User.find(team_user.user_id)
if SignedUpTeam.where( :team_id => team.id).where(:is_waitlisted => [false, nil," ", ""]).present?
assignemnt_team = SignedUpTeam.where( :team_id => team.id).where(:is_waitlisted => [false, nil," ", ""]).first
topic = SignUpTopic.find(assignemnt_team.topic_id)
csv << [
user.name,
user.fullname,
user.email,
user.role.name,
user.parent.name,
user.email_on_submission,
user.email_on_review,
user.email_on_review_of_review,
team.id,
topic.topic_name,
"handle"
]
end
end
end

====UI Testing====
UI testing for the above was done by exporting Assignment Teams for a given assignment using all the above options individually and checking if the result actually matched what was expected. Example 'all' should export all the participants listed withing the assignment. 'Signed Up Team' gives all the participants who have signed up mapped to their teams and respective topics.
If you are signed in as Instructor:
Feature can be tested by clicking on add participants button in manage assignments and then clicking on export course participants at the bottom of the page. And then following the applicable option for testing the respective features described above.

==Ordering of Imported Fields (Issue 110)==
====Current Implementation====

Currently the order of the columns is preset and the user has to change the csv to match it.

=====Drawbacks and Solutions=====

This is inconvenient for the user to keep editing csv files. The solution iss to allow users chose the order of the columns as it appears in their csv file.

====New Implementation====
In the view we added the drop down fields based on the expected_fields

*Please choose the order of the columns here: 
<%@array_expected_values.each{|field|%>
<%=select_tag 'import_field_[field]', options_for_select(@array_expected_values.collect.with_index.to_a,field)%> 
<%}%>

In the import_file_controller.rb we made addition to the start method:

@array_expected_values = parse_line(@expected_fields,',',params)
b = ['...','MetareviewerN','ReviewerN','Team MemberN']
@array_expected_values.delete_if { |x| b.include?(x) }
if(@array_expected_values.include?("Team Member1"))
(3..4).each do |i|
@array_expected_values.push("Team Member#{i}")
end
elsif(@array_expected_values.include?("Reviewer1"))
(3..15).each do |i|
@array_expected_values.push("Reviewer#{i}")
end
elsif(@array_expected_values.include?("Metaeviewer1"))
(3..15).each do |i|
@array_expected_values.push("Metareviewer#{i}")
end

This allows expected_fields for the users and reviews to be unpacked as previously it was using wording such as "... userN"

Also in the import_file_controller.rb we added function that reorders the columns as they are expected by expertiza:

def reorder_row(row,params)
case params[:model]
when "AssignmentTeam"
expected_fields_variable_default = ['Team Name - optional', 'Team Member1','Team Member2', 'Team Member3', 'Team Member4']
when "User"
expected_fields_variable_default = [ 'username', 'full name (first[ middle] last)', 'e-mail address']
when "ReviewResponseMap"
expected_fields_variable_default = [ 'Contributor', 'Reviewer1', 'Reviewer2']
(3..15).each do |i|
expected_fields_variable_default.push("Reviewer#{i}")
end
when "MetaeviewResponseMap"
expected_fields_variable_default = [ 'Contributor', 'Reviewer', 'Metareviewer1','Metareviewer2']
(3..15).each do |i|
expected_fields_variable_default.push("Metareviewer#{i}")
end
when "SignUpTopic"
expected_fields_variable_default = [ 'Topic identifier', 'Topic name', 'Max choosers', 'Topic Category']
else
expected_fields_variable_default = ['Team Name - optional', 'Team Member1','Team Member2', 'Team Member3', 'Team Member4']
end
expected_fields_variable=[]
custom_order={}
return_row=[]
expected_fields_variable=expected_fields_variable_default.reject.with_index { |x,i| i > row.length-1 }
expected_fields_variable.each_with_index { |field, index|
custom_order[params["import_field_#{index}"]]=row[index]
}
expected_fields_variable.each_with_index { |field, index| return_row[index]=custom_order[field]}
return_row
end

==Improvement Scope ==
The above Import as well as export functionalities that have been implemented in due course of the project have a scope for improvement. Imports and exports are functionalities that are used very often used to insert data as well to transfer data stored into the Models to external CSV files. Thus these features can be further tested using rspec tests as well as capybara and cucumber tests so as to make it fool proof. However these tests cannot be made such that they hamper the flexibility of the implementation to achieve a particular functionality.
Further We can also add options to handle duplicates as well as to filter out exports in other models as well, instead of the ones it is already present. Thus there is a scope of a lot more improvement to make Expertiza more user friendly.

CSC/ECE 517 Fall 2016/oss E1656

2016-10-29T03:58:43Z

Rsinha2: /* References */

CSC/ECE 517 Fall 2016/oss E1656

2016-10-29T02:05:02Z

Rsinha2: /* Improvement Scope */

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T21:52:48Z

Rsinha2: /* UI Testing */

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T21:44:27Z

Rsinha2: /* UI Testing */

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T15:53:57Z

Rsinha2: /* Export Assignment Participants */

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T15:39:58Z

Rsinha2: /* Handle Duplicates */

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T15:09:53Z

Rsinha2: /* New Implementation */

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T05:00:24Z

Rsinha2: /* About Versions Controller */

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T04:56:39Z

Rsinha2:

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T04:55:03Z

Rsinha2: /* Handle Duplicates */

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T04:54:48Z

Rsinha2: /* About Versions Controller */

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T04:54:32Z

Rsinha2: /* Problem Statement */

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T04:54:08Z

Rsinha2: /* Introduction to Expertiza */

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T04:37:15Z

Rsinha2: /* Current Implementation */

==E1656. Improve imports==

This page provides a description of the Expertiza based OSS project.

__TOC__

===Introduction to Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework.

===Problem Statement===
The following tasks were listed for this project:
*The simplest fix: If I try to import topics, the import page gives me this message: “The import process expects the following columns:” but it doesn’t say what the columns are (topic number, topic name, category, number of slots, category)! It used to be in the system; please revert the change to fix this bug. See Issue 719.
*When teams are imported in order to insert new members, the members are not inserted. See Issue 328.
*When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
*Review assignments (“reviewer mappings”) should be able to be imported, but cannot be imported. See Issue 711
*It should be possible to import a list of users who have signed up for topics, but this feature does not yet exist. See Issue 153.
*It should be possible to leave off the final fields in a line of a CSV file. These fields are often not specified anyway. For example, if a password isn’t specified when a new user is created, the system generates a password (see Issue 183). When importing topics, topic categories are rarely specified. But if the final field is blank, the import requires the CSV line to end with “, “ (comma and space). This should be fixed for all imports.
*For every kind of data to be imported, Expertiza currently specifies the ordering of fields. This isn’t very flexible; it may require the user (an instructor) to edit an existing CSV file. It would be better if, after importing the data, Expertiza showed the data together with dropdowns containing the default field headers. (This is similar to the way Excel shows data when it is imported from a CSV file.) Then the user could change the dropdowns to cause a different ordering of fields. See Issue 110.
*Create a way to export a list of teams that have signed up for topics, and who are waitlisted for topics, as well as participants in an assignment who have not signed up for topics. Choose the format, but keep it as consistent as possible with the other export formats. This would help the professor when students ask him for advice on finding teammates.

===About Versions Controller===

===Handle Duplicates===
====Current Implementation====

'''When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
'''The current implementation allows the user to handle duplicates, by the following techniques
*ignore the new team
*replace the existing team with the new team
*insert any new members into the existing team
*rename the new team and import
*rename the existing team and import

=====Functionality=====

The above functionalities make it easier to achieve the goal of handling duplicates while importing.

=====Drawbacks and Solutions=====

The above set of functionalities do not allow User to ever rename an existing team, rather force him rename his own team.
Thus the above requirement provides the necessary freedom to the User by providing him the option to rename an already existing team.

====New Implementation====

The option has been implemented using the update functionality that is already present in rails models, to update existing values of Active Records. To implement this feature we have also made use of the functionality for generating team names, that is already present within the Team model.

A code snippet is given below:
if handle_dups == "renameOldTeam" # rename: rename new team
if teamtype.is_a?(CourseTeam)
CourseTeam.update(team.id, :name => self.generate_team_name(Course.find(id).name))
return name
elsif teamtype.is_a?(AssignmentTeam)
AssignmentTeam.update(team.id, :name => self.generate_team_name(Assignment.find(id).name))
return name
end
end

===Export Assignment Participants===
====Current Implementation====
Current Implementation just allows users to Export the set of all Assignment Participants, of a given assignment. It doesn't allow any further filtering.

====Functionality====
The current functionality is very rigid and doesn't allow the user to know any more than the set of assignment Participants, which is also a major drawback

====New Implementation====
The new implementation allows user to export Assignment Participants in four ways.
* List of All Users mapped with team number and topic name who have signed up for an assignment topic
* List of All Users mapped with team number and topic name who are wait-listed for an assignment topic
* List of All Participants who haven't yet signed up for a topic and haven't formed teams yet
* List of All Participants

The functionality is present as a set of Radio buttons, which is checked by default to the fourth option that is to export all Participants. However that can be changed according to requirement.

The above has been implemented by creating a partial for the view to add the radio button. Further and If else bock has been used in the model, to identify the option selected and accordingly, on the required set of Rows are pushed to the csv file. To know whether a User has signed up or not for a topic, The SignedUpTeam model is used and to find if the team is wait listed or not, the is_waitlisted boolean value id used to determine if the team is wait listed or not.

===Code improvements===

===Testing ===
====Rspec testing====
====UI testing====

===References===

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T04:34:42Z

Rsinha2: /* Export Participants */

==E1656. Improve imports==

This page provides a description of the Expertiza based OSS project.

__TOC__

===Introduction to Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework.

===Problem Statement===
The following tasks were listed for this project:
*The simplest fix: If I try to import topics, the import page gives me this message: “The import process expects the following columns:” but it doesn’t say what the columns are (topic number, topic name, category, number of slots, category)! It used to be in the system; please revert the change to fix this bug. See Issue 719.
*When teams are imported in order to insert new members, the members are not inserted. See Issue 328.
*When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
*Review assignments (“reviewer mappings”) should be able to be imported, but cannot be imported. See Issue 711
*It should be possible to import a list of users who have signed up for topics, but this feature does not yet exist. See Issue 153.
*It should be possible to leave off the final fields in a line of a CSV file. These fields are often not specified anyway. For example, if a password isn’t specified when a new user is created, the system generates a password (see Issue 183). When importing topics, topic categories are rarely specified. But if the final field is blank, the import requires the CSV line to end with “, “ (comma and space). This should be fixed for all imports.
*For every kind of data to be imported, Expertiza currently specifies the ordering of fields. This isn’t very flexible; it may require the user (an instructor) to edit an existing CSV file. It would be better if, after importing the data, Expertiza showed the data together with dropdowns containing the default field headers. (This is similar to the way Excel shows data when it is imported from a CSV file.) Then the user could change the dropdowns to cause a different ordering of fields. See Issue 110.
*Create a way to export a list of teams that have signed up for topics, and who are waitlisted for topics, as well as participants in an assignment who have not signed up for topics. Choose the format, but keep it as consistent as possible with the other export formats. This would help the professor when students ask him for advice on finding teammates.

===About Versions Controller===

===Handle Duplicates===
====Current Implementation====

'''When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
'''The current implementation allows the user to handle duplicates, by the following techniques
*ignore the new team
*replace the existing team with the new team
*insert any new members into the existing team
*rename the new team and import
*rename the existing team and import

=====Functionality=====

The above functionalities make it easier to achieve the goal of handling duplicates while importing.

=====Drawbacks and Solutions=====

The above set of functionalities do not allow User to ever rename an existing team, rather force him rename his own team.
Thus the above requirement provides the necessary freedom to the User by providing him the option to rename an already existing team.

====New Implementation====

The option has been implemented using the update functionality that is already present in rails models, to update existing values of Active Records. To implement this feature we have also made use of the functionality for generating team names, that is already present within the Team model.

A code snippet is given below:
if handle_dups == "renameOldTeam" # rename: rename new team
if teamtype.is_a?(CourseTeam)
CourseTeam.update(team.id, :name => self.generate_team_name(Course.find(id).name))
return name
elsif teamtype.is_a?(AssignmentTeam)
AssignmentTeam.update(team.id, :name => self.generate_team_name(Assignment.find(id).name))
return name
end
end

===Export Assignment Participants===
====Current Implementation====
Current Implementation just allows users to Export the set of all Assignment Participants, of a given assignment. It doesn't allow ant further filtering.

====New Implementation====
The new implementation allows user to export Assignment Participants in four ways.
* List of All Users mapped with team number and topic name who have signed up for an assignment topic
* List of All Users mapped with team number and topic name who are wait-listed for an assignment topic
* List of All Participants who haven't yet signed up for a topic and haven't formed teams yet
* List of All Participants

The functionality is present as a set of Radio buttons, which is checked by default to the fourth option that is to export all Participants. However that can be changed according to requirement.

The above has been implemented by creating a partial for the view to add the radio button. Further and If else bock has been used in the model, to identify the option selected and accordingly, on the required set of Rows are pushed to the csv file. To know whether a User has signed up or not for a topic, The SignedUpTeam model is used and to find if the team is wait listed or not, the is_waitlisted boolean value id used to determine if the team is wait listed or not.

===Code improvements===

===Testing ===
====Rspec testing====
====UI testing====

===References===

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T04:22:54Z

Rsinha2: /* =New Implementation */

==E1656. Improve imports==

This page provides a description of the Expertiza based OSS project.

__TOC__

===Introduction to Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework.

===Problem Statement===
The following tasks were listed for this project:
*The simplest fix: If I try to import topics, the import page gives me this message: “The import process expects the following columns:” but it doesn’t say what the columns are (topic number, topic name, category, number of slots, category)! It used to be in the system; please revert the change to fix this bug. See Issue 719.
*When teams are imported in order to insert new members, the members are not inserted. See Issue 328.
*When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
*Review assignments (“reviewer mappings”) should be able to be imported, but cannot be imported. See Issue 711
*It should be possible to import a list of users who have signed up for topics, but this feature does not yet exist. See Issue 153.
*It should be possible to leave off the final fields in a line of a CSV file. These fields are often not specified anyway. For example, if a password isn’t specified when a new user is created, the system generates a password (see Issue 183). When importing topics, topic categories are rarely specified. But if the final field is blank, the import requires the CSV line to end with “, “ (comma and space). This should be fixed for all imports.
*For every kind of data to be imported, Expertiza currently specifies the ordering of fields. This isn’t very flexible; it may require the user (an instructor) to edit an existing CSV file. It would be better if, after importing the data, Expertiza showed the data together with dropdowns containing the default field headers. (This is similar to the way Excel shows data when it is imported from a CSV file.) Then the user could change the dropdowns to cause a different ordering of fields. See Issue 110.
*Create a way to export a list of teams that have signed up for topics, and who are waitlisted for topics, as well as participants in an assignment who have not signed up for topics. Choose the format, but keep it as consistent as possible with the other export formats. This would help the professor when students ask him for advice on finding teammates.

===About Versions Controller===

===Handle Duplicates===
====Current Implementation====

'''When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
'''The current implementation allows the user to handle duplicates, by the following techniques
*ignore the new team
*replace the existing team with the new team
*insert any new members into the existing team
*rename the new team and import
*rename the existing team and import

=====Functionality=====

The above functionalities make it easier to achieve the goal of handling duplicates while importing.

=====Drawbacks and Solutions=====

The above set of functionalities do not allow User to ever rename an existing team, rather force him rename his own team.
Thus the above requirement provides the necessary freedom to the User by providing him the option to rename an already existing team.

====New Implementation====

The option has been implemented using the update functionality that is already present in rails models, to update existing values of Active Records. To implement this feature we have also made use of the functionality for generating team names, that is already present within the Team model.

A code snippet is given below:
if handle_dups == "renameOldTeam" # rename: rename new team
if teamtype.is_a?(CourseTeam)
CourseTeam.update(team.id, :name => self.generate_team_name(Course.find(id).name))
return name
elsif teamtype.is_a?(AssignmentTeam)
AssignmentTeam.update(team.id, :name => self.generate_team_name(Assignment.find(id).name))
return name
end
end

===Export Participants===
===Code improvements===

===Testing ===
====Rspec testing====
====UI testing====

===References===

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T04:22:44Z

Rsinha2: /* =Current Implementation */

==E1656. Improve imports==

This page provides a description of the Expertiza based OSS project.

__TOC__

===Introduction to Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework.

===Problem Statement===
The following tasks were listed for this project:
*The simplest fix: If I try to import topics, the import page gives me this message: “The import process expects the following columns:” but it doesn’t say what the columns are (topic number, topic name, category, number of slots, category)! It used to be in the system; please revert the change to fix this bug. See Issue 719.
*When teams are imported in order to insert new members, the members are not inserted. See Issue 328.
*When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
*Review assignments (“reviewer mappings”) should be able to be imported, but cannot be imported. See Issue 711
*It should be possible to import a list of users who have signed up for topics, but this feature does not yet exist. See Issue 153.
*It should be possible to leave off the final fields in a line of a CSV file. These fields are often not specified anyway. For example, if a password isn’t specified when a new user is created, the system generates a password (see Issue 183). When importing topics, topic categories are rarely specified. But if the final field is blank, the import requires the CSV line to end with “, “ (comma and space). This should be fixed for all imports.
*For every kind of data to be imported, Expertiza currently specifies the ordering of fields. This isn’t very flexible; it may require the user (an instructor) to edit an existing CSV file. It would be better if, after importing the data, Expertiza showed the data together with dropdowns containing the default field headers. (This is similar to the way Excel shows data when it is imported from a CSV file.) Then the user could change the dropdowns to cause a different ordering of fields. See Issue 110.
*Create a way to export a list of teams that have signed up for topics, and who are waitlisted for topics, as well as participants in an assignment who have not signed up for topics. Choose the format, but keep it as consistent as possible with the other export formats. This would help the professor when students ask him for advice on finding teammates.

===About Versions Controller===

===Handle Duplicates===
====Current Implementation====

'''When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
'''The current implementation allows the user to handle duplicates, by the following techniques
*ignore the new team
*replace the existing team with the new team
*insert any new members into the existing team
*rename the new team and import
*rename the existing team and import

=====Functionality=====

The above functionalities make it easier to achieve the goal of handling duplicates while importing.

=====Drawbacks and Solutions=====

The above set of functionalities do not allow User to ever rename an existing team, rather force him rename his own team.
Thus the above requirement provides the necessary freedom to the User by providing him the option to rename an already existing team.

====New Implementation===

The option has been implemented using the update functionality that is already present in rails models, to update existing values of Active Records. To implement this feature we have also made use of the functionality for generating team names, that is already present within the Team model.

A code snippet is given below:
if handle_dups == "renameOldTeam" # rename: rename new team
if teamtype.is_a?(CourseTeam)
CourseTeam.update(team.id, :name => self.generate_team_name(Course.find(id).name))
return name
elsif teamtype.is_a?(AssignmentTeam)
AssignmentTeam.update(team.id, :name => self.generate_team_name(Assignment.find(id).name))
return name
end
end
===Export Participants===
===Code improvements===

===Testing ===
====Rspec testing====
====UI testing====

===References===

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T04:22:28Z

Rsinha2: /* E1656. Improve imports */

==E1656. Improve imports==

This page provides a description of the Expertiza based OSS project.

__TOC__

===Introduction to Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework.

===Problem Statement===
The following tasks were listed for this project:
*The simplest fix: If I try to import topics, the import page gives me this message: “The import process expects the following columns:” but it doesn’t say what the columns are (topic number, topic name, category, number of slots, category)! It used to be in the system; please revert the change to fix this bug. See Issue 719.
*When teams are imported in order to insert new members, the members are not inserted. See Issue 328.
*When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
*Review assignments (“reviewer mappings”) should be able to be imported, but cannot be imported. See Issue 711
*It should be possible to import a list of users who have signed up for topics, but this feature does not yet exist. See Issue 153.
*It should be possible to leave off the final fields in a line of a CSV file. These fields are often not specified anyway. For example, if a password isn’t specified when a new user is created, the system generates a password (see Issue 183). When importing topics, topic categories are rarely specified. But if the final field is blank, the import requires the CSV line to end with “, “ (comma and space). This should be fixed for all imports.
*For every kind of data to be imported, Expertiza currently specifies the ordering of fields. This isn’t very flexible; it may require the user (an instructor) to edit an existing CSV file. It would be better if, after importing the data, Expertiza showed the data together with dropdowns containing the default field headers. (This is similar to the way Excel shows data when it is imported from a CSV file.) Then the user could change the dropdowns to cause a different ordering of fields. See Issue 110.
*Create a way to export a list of teams that have signed up for topics, and who are waitlisted for topics, as well as participants in an assignment who have not signed up for topics. Choose the format, but keep it as consistent as possible with the other export formats. This would help the professor when students ask him for advice on finding teammates.

===About Versions Controller===

===Handle Duplicates===
====Current Implementation===

'''When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
'''The current implementation allows the user to handle duplicates, by the following techniques
*ignore the new team
*replace the existing team with the new team
*insert any new members into the existing team
*rename the new team and import
*rename the existing team and import

=====Functionality=====

The above functionalities make it easier to achieve the goal of handling duplicates while importing.

=====Drawbacks and Solutions=====

The above set of functionalities do not allow User to ever rename an existing team, rather force him rename his own team.
Thus the above requirement provides the necessary freedom to the User by providing him the option to rename an already existing team.

====New Implementation===

The option has been implemented using the update functionality that is already present in rails models, to update existing values of Active Records. To implement this feature we have also made use of the functionality for generating team names, that is already present within the Team model.

A code snippet is given below:
if handle_dups == "renameOldTeam" # rename: rename new team
if teamtype.is_a?(CourseTeam)
CourseTeam.update(team.id, :name => self.generate_team_name(Course.find(id).name))
return name
elsif teamtype.is_a?(AssignmentTeam)
AssignmentTeam.update(team.id, :name => self.generate_team_name(Assignment.find(id).name))
return name
end
end
===Export Participants===
===Code improvements===

===Testing ===
====Rspec testing====
====UI testing====

===References===

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T04:19:45Z

Rsinha2: /* Current Implementation */

==E1656. Improve imports==

This page provides a description of the Expertiza based OSS project.

__TOC__

===Introduction to Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework.

===Problem Statement===
The following tasks were listed for this project:
*The simplest fix: If I try to import topics, the import page gives me this message: “The import process expects the following columns:” but it doesn’t say what the columns are (topic number, topic name, category, number of slots, category)! It used to be in the system; please revert the change to fix this bug. See Issue 719.
*When teams are imported in order to insert new members, the members are not inserted. See Issue 328.
*When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
*Review assignments (“reviewer mappings”) should be able to be imported, but cannot be imported. See Issue 711
*It should be possible to import a list of users who have signed up for topics, but this feature does not yet exist. See Issue 153.
*It should be possible to leave off the final fields in a line of a CSV file. These fields are often not specified anyway. For example, if a password isn’t specified when a new user is created, the system generates a password (see Issue 183). When importing topics, topic categories are rarely specified. But if the final field is blank, the import requires the CSV line to end with “, “ (comma and space). This should be fixed for all imports.
*For every kind of data to be imported, Expertiza currently specifies the ordering of fields. This isn’t very flexible; it may require the user (an instructor) to edit an existing CSV file. It would be better if, after importing the data, Expertiza showed the data together with dropdowns containing the default field headers. (This is similar to the way Excel shows data when it is imported from a CSV file.) Then the user could change the dropdowns to cause a different ordering of fields. See Issue 110.
*Create a way to export a list of teams that have signed up for topics, and who are waitlisted for topics, as well as participants in an assignment who have not signed up for topics. Choose the format, but keep it as consistent as possible with the other export formats. This would help the professor when students ask him for advice on finding teammates.

===About Versions Controller===

===Current Implementation===

'''When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
'''The current implementation allows the user to handle duplicates, by the following techniques
*ignore the new team
*replace the existing team with the new team
*insert any new members into the existing team
*rename the new team and import
*rename the existing team and import

=====Functionality=====

The above functionalities make it easier to achieve the goal of handling duplicates while importing.

=====Drawbacks and Solutions=====

The above set of functionalities do not allow User to ever rename an existing team, rather force him rename his own team.
Thus the above requirement provides the necessary freedom to the User by providing him the option to rename an already existing team.

===New Implementation===

The option has been implemented using the update functionality that is already present in rails models, to update existing values of Active Records. To implement this feature we have also made use of the functionality for generating team names, that is already present within the Team model.

A code snippet is given below:
if handle_dups == "renameOldTeam" # rename: rename new team
if teamtype.is_a?(CourseTeam)
CourseTeam.update(team.id, :name => self.generate_team_name(Course.find(id).name))
return name
elsif teamtype.is_a?(AssignmentTeam)
AssignmentTeam.update(team.id, :name => self.generate_team_name(Assignment.find(id).name))
return name
end
end

===Code improvements===

===Testing ===
====Rspec testing====
====UI testing====

===References===

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T04:18:52Z

Rsinha2: /* New Implementation */

==E1656. Improve imports==

This page provides a description of the Expertiza based OSS project.

__TOC__

===Introduction to Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework.

===Problem Statement===
The following tasks were listed for this project:
*The simplest fix: If I try to import topics, the import page gives me this message: “The import process expects the following columns:” but it doesn’t say what the columns are (topic number, topic name, category, number of slots, category)! It used to be in the system; please revert the change to fix this bug. See Issue 719.
*When teams are imported in order to insert new members, the members are not inserted. See Issue 328.
*When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
*Review assignments (“reviewer mappings”) should be able to be imported, but cannot be imported. See Issue 711
*It should be possible to import a list of users who have signed up for topics, but this feature does not yet exist. See Issue 153.
*It should be possible to leave off the final fields in a line of a CSV file. These fields are often not specified anyway. For example, if a password isn’t specified when a new user is created, the system generates a password (see Issue 183). When importing topics, topic categories are rarely specified. But if the final field is blank, the import requires the CSV line to end with “, “ (comma and space). This should be fixed for all imports.
*For every kind of data to be imported, Expertiza currently specifies the ordering of fields. This isn’t very flexible; it may require the user (an instructor) to edit an existing CSV file. It would be better if, after importing the data, Expertiza showed the data together with dropdowns containing the default field headers. (This is similar to the way Excel shows data when it is imported from a CSV file.) Then the user could change the dropdowns to cause a different ordering of fields. See Issue 110.
*Create a way to export a list of teams that have signed up for topics, and who are waitlisted for topics, as well as participants in an assignment who have not signed up for topics. Choose the format, but keep it as consistent as possible with the other export formats. This would help the professor when students ask him for advice on finding teammates.

===About Versions Controller===

===Current Implementation===

When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
The current implementation allows the user to handle duplicates, by the following techniques
*ignore the new team
*replace the existing team with the new team
*insert any new members into the existing team
*rename the new team and import
*rename the existing team and import

=====Functionality=====

The above functionalities make it easier to achieve the goal of handling duplicates while importing.

=====Drawbacks and Solutions=====

The above set of functionalities do not allow User to ever rename an existing team, rather force him rename his own team.
Thus the above requirement provides the necessary freedom to the User by providing him the option to rename an already existing team.

===New Implementation===

The option has been implemented using the update functionality that is already present in rails models, to update existing values of Active Records. To implement this feature we have also made use of the functionality for generating team names, that is already present within the Team model.

A code snippet is given below:
if handle_dups == "renameOldTeam" # rename: rename new team
if teamtype.is_a?(CourseTeam)
CourseTeam.update(team.id, :name => self.generate_team_name(Course.find(id).name))
return name
elsif teamtype.is_a?(AssignmentTeam)
AssignmentTeam.update(team.id, :name => self.generate_team_name(Assignment.find(id).name))
return name
end
end

===Code improvements===

===Testing ===
====Rspec testing====
====UI testing====

===References===

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T04:15:21Z

Rsinha2: /* New Implementation */

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T04:11:58Z

Rsinha2: /* Current Implementation */

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T03:58:48Z

Rsinha2: /* Introduction to Expertiza */

CSC/ECE 517 Fall 2016/oss E1656

2016-10-28T03:58:29Z

Rsinha2: /* Introduction to Expertiza */

==E1656. Improve imports==

This page provides a description of the Expertiza based OSS project.

__TOC__

===Introduction to Expertiza===
____________________________________________________________________________________________________________________________________________________________
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework.

===Problem Statement===
The following tasks were listed for this project:
*The simplest fix: If I try to import topics, the import page gives me this message: “The import process expects the following columns:” but it doesn’t say what the columns are (topic number, topic name, category, number of slots, category)! It used to be in the system; please revert the change to fix this bug. See Issue 719.
*When teams are imported in order to insert new members, the members are not inserted. See Issue 328.
*When a team with a duplicate name is imported, one of the options is to rename the new team. There should also be an option to rename an existing team. See Issue 329.
*Review assignments (“reviewer mappings”) should be able to be imported, but cannot be imported. See Issue 711
*It should be possible to import a list of users who have signed up for topics, but this feature does not yet exist. See Issue 153.
*It should be possible to leave off the final fields in a line of a CSV file. These fields are often not specified anyway. For example, if a password isn’t specified when a new user is created, the system generates a password (see Issue 183). When importing topics, topic categories are rarely specified. But if the final field is blank, the import requires the CSV line to end with “, “ (comma and space). This should be fixed for all imports.
*For every kind of data to be imported, Expertiza currently specifies the ordering of fields. This isn’t very flexible; it may require the user (an instructor) to edit an existing CSV file. It would be better if, after importing the data, Expertiza showed the data together with dropdowns containing the default field headers. (This is similar to the way Excel shows data when it is imported from a CSV file.) Then the user could change the dropdowns to cause a different ordering of fields. See Issue 110.
*Create a way to export a list of teams that have signed up for topics, and who are waitlisted for topics, as well as participants in an assignment who have not signed up for topics. Choose the format, but keep it as consistent as possible with the other export formats. This would help the professor when students ask him for advice on finding teammates.

===About Versions Controller===

===Current Implementation===

=====Functionality=====

=====Drawbacks and Solutions=====

===New Implementation===

===Code improvements===

===Testing ===
====Rspec testing====
====UI testing====

===References===