CSC/ECE 517 Fall 2016/oss E1656

E1656. Improve imports

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

Introduction to Expertiza

Expertiza is an open source project based on Ruby on Rails framework.

Problem Statement

The following tasks were implmeted in this project:

• 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.

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

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

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.

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.