CSC/ECE 517 Spring 2018 - E1800: Add past-due assignments to task list

About Expertiza

Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities. -- Expertiza project

Project E1800 Overview

For the E1800 project, a course project for CSC 517 at NCSU during the Spring of 2018, certain improvements were made to the Expertiza system. Primarily, the goal of this project was to add past-due assignments to the student task list. The full list of tasks (the original task list with modifications from instructor feedback) is:

• Issue #80: Add past-due assignments to task list (on Student Task page).
• Highlight with specific colors current and next due dates (on Student Task page).
• Check for correction in due dates of assignments
• On the Student Task page, separate the list of 'teamed with' students from the current tasks box.
• Show required action on: every student has to review others work and give feedback.
• Write all the required tests before implementing/refactoring the methods in the above mentioned classes.

Some Additional tasks accomplished by our team are:

• Added pagination to past-due assignments on task list
• Made various UI enhancements to the student_tasks page, specifically regarding the layout of elements.
• Refactored student_task_controller.rb

Files modified

student_task_controller.erb
app/views/student_task/list.html.erb
student_task_helper.rb
airbrake_exception_errors_feature_tests_spec.rb

New files

will_paginate_array_fix.rb student_task_feature_spec.rb

Adding past-due assignments to task page

Currently, the student task list consists of one list of all assignments that are and have been assigned to the student regardless of their due date. Now a separate table exists for assignments that are past due. This table is sorted to show the most recent past due assignments at the top of the table. The table that used to be all student tasks is now assignments that are currently due. This table is sorted by due date to show assignments that are due the soonest at the top of the table.

This change mostly involved changes to the student_task_controller.rb and list.html.erb files. A helper function was also added to the student_task_helper.rb file to break a string into multiple lines, even in the middle of a word, if it contains a word that is very long.

In the student_task_controller.rb, a separate instance variable was created to contain only student tasks that are past due and sorted by date. The existing instance variable was recycled to contain all of the student tasks that are still currently due.

In the list.html.erb file a new table was created to hold all of the past assignments. Both the current assignments and past assignments tables are also individually paginated if there are more than 10 of either.

To create the ability for the will_paginate gem to add pagination based on an array the will_paginate_array_fix.rb file was added to the initializers folder.

Highlighting current and next due dates

Currently, all of the tasks in the table have a white background regardless of when the task is due. To make it more apparent when due dates are approaching, each row will now highlight green, yellow, orange, or red depending on how many days out the assignment is due.

This change involved adding a function to the student_task_helper.rb file as well as a change in list.html.erb.

The change in student_task_helper.rb was a function that receives a due_date in Time format, converts it to DateTime then does a subtraction to DateTime.now to get how many days until the due date. Based on the result the function will return a string containing a color that will be the background of an individual row in the current assignments table.

Check for correction in due dates

After speaking with our mentor, we came to the conclusion that this was not an issue; therefore meaning no changes needed to be made for this point.

Separate Teamed-with list from task list

Currently, the current tasks list, as well as students you have worked with, exist in the same box. This looks cluttered, so they have been separated to be their own boxes.

This change involved editing list.html.erb.

The information about students you have worked with was moved out of the existing "taskbox" div tag and into its own "taskbox" div tag to separate it.

Show required action for reviews

Presently, the required actions list does not show entries for review tasks. That is, the list only displays tasks that have yet to be started. Therefore, once an assignment has been submitted, additional required actions such as reviews do not appear. In order to solve this problem, a few lines of code were added to student_task_controller.rb. This code retrieved all active student tasks, and adds tasks which both are in the review phase and for which the student has yet to submit a review to the required task list.

In addition, a bit of creative discretion was used and an icon was added to draw the user towards the Review link when it is active. This can be seen in the capture below. The current assignments will show all assignments that are not completed, and if the assignment is in the review phase, it will display a small warning icon indicating action needs to be taken. The screenshot below demonstrates this on the "Unknown" stage, since, because of the afromentioned issues with testing, an assignment in the review phase could not be created for testing purposes. However, the logic is in the view, and is a simple string compare, so if the stage is in Review, the icon will show up.

Separating current and past task lists

As mentioned in the “Adding past-due assignments to task page” task, the primary assignment list on the student_task page has been updated. In our new version, the list separates tasks that have been completed from ongoing tasks. This both improves the page aesthetically as well as draws attention to ongoing tasks. Previously, these were often buried underneath many past tasks which were already completed.

Added pagination of past-due assignments

Another task completed which enhances the usability of the student_task page is adding pagination to current and past assignments. Specifically, If there are more than 10 past or current assignments due, each table will individually paginate. Meaning you could be on page 2 of current assignments but also page 4 of past assignments. This makes the lists easier to read and parse for users with many tasks.

Refactored student_task_controller.rb

Prior to this project, the Code Coverage report displayed many warnings for student_task_controller.rb. Primarily, these warnings were clear signs of excessively high complexity within methods. In several cases, the cyclomatic complexity of methods was too high. In others, the perceived complexity or assignment branch condition size was too great. In order to fix as many of these issues as possible, the class was refactored. In some cases, several comments within methods were used in order to divide one method into logical pieces, a clear code smell. In order to fix many of these issues, the "Extract Method" refactor was used. That is, methods were split into more logical, easier to read and follow pieces. Several other refactoring methods were utilized to make this file easier to understand, as it does perform many separate logical tasks.

For example, the method view was flagged in Code Climate with the message: Assignment Branch Condition size for view is too high. [24.62/15]. In order to correct this, the original method:

 def view
   StudentTask.from_participant_id params[:id]
   @participant = AssignmentParticipant.find(params[:id])
   @can_submit = @participant.can_submit
   @can_review = @participant.can_review
   @can_take_quiz = @participant.can_take_quiz
   @authorization = Participant.get_authorization(@can_submit, @can_review, @can_take_quiz)
   @team = @participant.team
   denied unless current_user_id?(@participant.user_id)
   @assignment = @participant.assignment
   @can_provide_suggestions = @assignment.allow_suggestions
   @topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
   @topics = SignUpTopic.where(assignment_id: @assignment.id)
   # Timeline feature
   @timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
 end

was refactored using the 'extract method' refactor, leading to the following, where init_participant, init_assignment, and init_timeline are separate, short, methods.

 def view
   StudentTask.from_participant_id params[:id]
   init_participant
   denied unless current_user_id?(@participant.user_id)
   init_assignment
   init_timeline
 end

Test Plan

The Lubuntu image was used to test our changes. We had trouble testing our changes on the normal .OVA distribution. For example, we could not conduct testing from an instructor's view and manage assignments and due dates, which was an important part of our test plan. The Lubuntu image resolved this, but, as can be seen below, invovles a slightly different user interface than the normal Expertiza.

As this documentation shows, much of our changes and features involved solely the view. Testing for our project revolved around simply ensuring that the view changed as per the various conditions defined. This method of navigating the site and ensuring if X, then Y should be Z is the best way to test in our case, since the view's final product, in the end, is a visual resultFor example, the coloration of due dates could be tested by navigating the site as a dev user, and making sure that if an assignment stage is due in more than ten days, then the row should be green. Likewise, if a stage is due in a day, the row should be red. . The steps to do this are:

1. Log in as an instructor
If logged in as instructor6, student563 is a student in your WCAE 2008 course

2. Select one of your courses(i.e WCAE 2008)

3. Click the create assignment icon

4. Enter an assignment name, use "./" as a submission directory, and add a rubric field.

5. Assign to a student/class


Make sure that the student you are adding is a student of the instructor you are logged in as. i.e student563 is a student of instructor6.

Also make sure to change the due dates

6. Check to see if the coloration works as expected (change the due date to test each case).

RSpec Tests

Rspec tests were written for the list method in the student_task_controller.rb file. There wasn't an existing student_task_controller_spec file so one was created to perform this testing. The testing consists of creating assignments with different attributes (due date in the future, due date in the past, and available or not) in order to test the functionality of the list method. Depending on what assignment gets tied to the student task, different instance variables will be populated with student tasks or be empty.

The four tests that were added are very similar in nature:
describe '#list' do

   context 'when there are available assignments due in the future' do
     it 'should populate all_tasks, student_tasks, and current_student_tasks instance variables with tasks' do
       session = {user: student}
       allow(StudentTask).to receive(:from_user).with(student).and_return([student_task_current])
       get :list, session
       expect(controller.instance_variable_get(:@all_tasks)).not_to be_empty
       expect(controller.instance_variable_get(:@student_tasks)).not_to be_empty
       expect(controller.instance_variable_get(:@current_student_tasks)).not_to be_empty
       expect(controller.instance_variable_get(:@past_student_tasks)).to be_empty
     end
   end

   context 'when there are available assignments due in the future' do
     it 'should populate past_student_tasks instance variable with tasks' do
       session = {user: student}
       allow(StudentTask).to receive(:from_user).with(student).and_return([student_task_past])
       get :list, session
       expect(controller.instance_variable_get(:@all_tasks)).not_to be_empty
       expect(controller.instance_variable_get(:@student_tasks)).not_to be_empty
       expect(controller.instance_variable_get(:@current_student_tasks)).to be_empty
       expect(controller.instance_variable_get(:@past_student_tasks)).not_to be_empty
     end
   end

   context 'when there are assignments but they are not available' do
     it 'should not populate the student_tasks instance variable with tasks' do
       session = {user: student}
       allow(StudentTask).to receive(:from_user).with(student).and_return([student_task_not_avail])
       get :list, session
       expect(controller.instance_variable_get(:@all_tasks)).not_to be_empty
       expect(controller.instance_variable_get(:@student_tasks)).to be_empty
       expect(controller.instance_variable_get(:@current_student_tasks)).to be_empty
       expect(controller.instance_variable_get(:@past_student_tasks)).to be_empty
     end
   end

   context 'when there are available assignments due in the future and in the past' do
     it 'should populate past_student_tasks and current_student_tasks instance variable with tasks' do
       session = {user: student}
       allow(StudentTask).to receive(:from_user).with(student).and_return([student_task_past, student_task_current])
       get :list, session
       expect(controller.instance_variable_get(:@all_tasks)).not_to be_empty
       expect(controller.instance_variable_get(:@student_tasks)).not_to be_empty
       expect(controller.instance_variable_get(:@current_student_tasks)).not_to be_empty
       expect(controller.instance_variable_get(:@past_student_tasks)).not_to be_empty
     end
   end
 end

These tests verify that the appropriate instance variables a being assigned to the correct values.These test were created to test the refactor that we performed on the list method of the student_task_controller.

Two checks were also added to the airbrake_exception_errors_feature_tests_spec.rb file where the list view is being loosely tested. These lines were added to verify that the "Current Assignments" table and the "Past Assignments" table have content.

 it "can access to '/student_task/list' after login as a student" do
   stu = create(:student)
   login_as stu.name
   visit '/tree_display/list'
   expect(page).to have_current_path('/student_task/list')
   expect(page).to have_content('Assignments')
   expect(page).to have_content('Current Assignments')
   expect(page).to have_content('Past Assignments')
   ...

However, refactoring was conducted and so RSpec tests were written for those instances.

As seen above, our pull request passes the Travis CI build.