CSC/ECE 517 Spring 2019 - Project E1930. Improving Search Facility in Expertiza

From Expertiza_Wiki
Jump to navigation Jump to search

Introduction:

The Expertiza application running on Ruby on Rails is used for a variety of purposes by students and faculty members. There are many pages that display information about students, assignments, rubrics and reviews. The information is displayed with attributes like name, ID, due date etc. This project works on improving the search facility by adding search criteria in existing search bars, making it look elegant and adding search bars if not present.


Problem Definition:

  1. An instructor or administrator can search for a user by name, user-ID, or other characteristics.
  2. An instructor should be able to search for assignments by name, due date, or other characteristics.
  3. An instructor should be able to search for rubrics (or other questionnaires) by name, or by the courses or assignments they have been used in.
    1. For the instructor, there also needs to be a way to quickly find rubrics (and other questionnaires) that have been used in a single course. It should be possible to search or click somewhere to bring up a list of questionnaires used in the course, expanding only the applicable questionnaires in the list of questionnaires.
    2. One should also be able to search for questionnaires by words used in questions that belong to the questionnaires.
  4. There should be a way to search all reviews of a particular team’s work for particular scores or text strings. Reviews should be able to be filtered by score, text comment length, reviewer and reviewee.
  5. An instructor or administrator should be able to search for all the assignments that a particular user has participated in.
  6. If more than one criteria needs to be specified, there should be an 'Advanced Search' button.


Proposed Solution:

Search for User:

In the current system workflow the user is able to search for a particular user by entering a partial or a complete text that matches with the user name. In the proposed workflow searching by name, searching by User ID will also be supported. The user will be able to apply multiple filters at a time and the output of the query will match all filter applied. If no results are found an empty list will be returned.

Steps to reproduce the proposed workflow:

  1. Log in to expertiza to view the home page
  2. Go to Manage > Users
  3. Type the name of the user in the search box available below the ‘Users’ tab
  4. In the dropdown list that opens up, click on the ‘Advanced Search’ button if you wish to apply more filters.
  5. All the entries that match the given criteria will be returned.


Search for Assignments:

In the current system implementation, searching via the name of the assignment is supported. In the proposed system, the user will be able to search for an assignment using additional filters such as date created, date updated. The user will be able to apply multiple filters at a time and the output of the query will match all filter applied. If no results are found an empty list will be returned.

To search for an assignment by creation date, the user can enter a time duration within which the assignment was created. All assignments that were created within this date range and which match other filters will be returned. The procedure is same for searching by date of update.

Steps to reproduce the proposed workflow:

  1. Log in to expertiza to view the home page
  2. Go to Manage > Assignments
  3. Type the name of the assignment in the search box available below the ‘Assignments’ tab
  4. In the dropdown list that opens up, click on the ‘Advanced Search’ button if you wish to apply more filters ( date of creation, date updated).
  5. All the entries that match the given criteria will be returned.

Search for Questionnaires:

The existing system does not have a search functionality under Questionnaires. The proposed system will implement a search functionality for searching via the name of the questionnaire, the text in the question within a questionnaire, date of creation, date updated. The user will be able to apply multiple filters at a time and the output of the query will match all filter applied. If no results are found an empty list will be returned.

To search for a course by creation date, the user can enter a time duration within which the course was created. All courses that were created within this date range and which match other filters will be returned. The procedure is same for searching by date of update. The questionnaires will be grouped on the basis of their courses and will be expanded when clicked.

All the above will be available under Manage > Questionnaires.


Search for Reviews:

The existing system does not have a search functionality under Reviews. The proposed system will implement a search functionality for searching using the attributes like team name, score, reviewer, comment etc.

Use Case Diagram

Proposed Code Changes

We though about 2 ways of adding the search functionality in the system

  1. Adding a search controller to the system
  2. Adding search functionality to individual models

Adding a search controller

If we followed this approach the search query would be like

  • localhost:port/search/user?name=<>
  • localhost:port/search/assignment?name=<>

This would mean that we are thinking of search as a resource on the system which to us looked as a wrong approach


Adding search functionality to individual models

If we followed this approach the search query would be like

  1. localhost:port/user/search?name=<>
  2. localhost:port/assignment/search?name=<>

On discussions we concluded that that the latter was a more RESTFul design For most of the cases we have tried to minimize the changes required in the respective model by reuse We propose to add search methods in each model for corresponding changes.

Therefore in order to perform search every entity required changes in all the three layers

  • View : Changes in view are changes added to UI, and it is used to pass search parameters to controller
  • Controller : Parses the changes from UI, essentially takes params[] hash.
  • Model : Bulk of search logic is implemented here, once the model gets the parameters for the search ( hash ), the query is incrementally built using all the params and then executed to get the list of objects.

User changes have been handled differently than for Questionnaire, Assignments and Review because Users follows the traditional RoR scheme, where as others user React for UI. React based View changes are in app/assets/javascripts/tree_display.jsx.

  • Also, placeholders are removed from the search text bars in advanced search because it looked ugly. Also, labels for each search text box has been added directly above it so that the user can easily identify what parameter that text field contains.
  • Also, code has been refactored because it was a lot of bad jumble in all the cases.
  • Comments have been extensively added throughout the code which are informative and helpful
  • Search functionality for Courses has been added as well.

User

  • Search fields
    • username
    • name
    • email
  • Modified files:
    • app/views/users/list.html.erb
    • app/controllers/users_controller.rb
    • app/models/user.rb
  • Modified functions
    • UsersController#list : Parses the username, name and email from the params hash.
    • User#get_user_list : Model returns list of users to the view, changes in this function uses regex to filter out the entries that do not match search params.

Assignment

  • Search fields
    • name
    • assignee_username
    • assignee_name
    • due_date_before
    • due_date_after
    • created_before
    • created_after
  • Modified files
    • app/assets/javascripts/tree_display.jsx
    • app/controllers/tree_display_controller.rb
    • app/models/assignment_node.rb
  • Modified functions
    • TreeDisplayController#initialize_fnode_update_children
    • TreeDisplayController#update_fnode_children
    • AssignmentNode.get

Questionnaire

  • Search fields
    • name
    • text
    • course
    • assignment
  • Modified files
    • app/assets/javascripts/tree_display.jsx
    • app/controllers/tree_display_controller.rb
    • app/models/questionnaire_node.rb
  • Modified functions
    • TreeDisplayController#get_tmp_res
    • QuestionnaireNode.get

Review

  • Search fields
    • team
    • text
    • min_score
    • max_score
  • Modified files
    • app/views/review_mapping/_searchbox.html.erb
    • app/controllers/review_mapping_controller.rb
    • app/helpers/summary_helper.rb
  • Modified functions
    • ReviewMappingController#response_report
    • SummaryHelper#summarize_reviews_by_reviewees

Courses

  • Search fields
    • Name

Screenshots

  • As seen in the image, the advanced search is closed at the start. When it is clicked on, it pops up as shown in the image below.
  • There is also an option of hiding the advanced search bar.

  • Important changes made in the pop-up of advanced search bar context was that, before when we tested the functionality it was found that if you had searched something prior in the advanced search bar, then if you hide the advanced search bar, the data remains persistent until it is removed manually.
  • Hence, if you search again now, it will take the prior advanced search criteria into consideration as well.
  • But now, the functionality has been changes to completely erase the data from the text boxes once it is hidden. So unwanted parameters are not included in the search.

Database Design

ER Diagram:

The simplified version of ER Diagram depicts relationships between the entity sets that are used in the system. Many-to-many relationships are identified by named-diamonds - teams_users, assignment_questionnaires, which are implemented as tables.


Relevant Tables

Test Plan:

We plan to two types of testing

  • User Interface manual testing
    • As extensive as these tests were, everything was found to be working correctly.
    • Feedback was taken as to where changes needed to be made and respective changes were made where necessary.
  • Automated RSpec testing
    • Tests were included for all the code refactoring done (making new subroutines and moving code.)
    • Also, there were extensive tests written for the search functionality which was dependent on the user that was logged in.
    • Basically, super admin were to be tested on different data than, TAs and instructors.
    • As an example:-
before(:each) do
      allow(user).to receive_message_chain("role.super_admin?") { false }
      allow(user).to receive_message_chain("role.instructor?") { false }
      allow(user).to receive_message_chain("role.ta?") { false }
      allow(SuperAdministrator).to receive(:get_user_list).and_return([user1, user2])
      allow(Instructor).to receive(:get_user_list).and_return([user1, user2])
      allow(Ta).to receive(:get_user_list).and_return([user1, user2])
    end

    context 'when current user is super admin' do
      it 'fetches all users' do
        allow(user).to receive_message_chain("role.super_admin?") { true }
        expect(user.get_user_list).to eq([user1, user2])
      end
    end

    context 'when current user is an instructor' do
      it 'fetches all users in his/her course/assignment' do
        allow(user).to receive_message_chain("role.instructor?") { true }
        expect(user.get_user_list).to eq([user1, user2])
      end
    end

Video Folder Link

[1]

Contributors

  • Dharmang Bhavsar
  • Vismay Golwala
  • Jason Katsaros
  • Yuzhe Zhu

Pull Request

https://github.com/expertiza/expertiza/pull/1452

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2019_-_Project_E1930._Improving_Search_Facility_in_Expertiza&oldid=124732"