CSC/ECE 517 Spring 2015 E1529 GLDS

E1529. Extend the Email notification feature to scheduled tasks

Overview

Introduction to Expertiza

Expertiza is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities<ref>Expertiza Github</ref>. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc). It is also a powerful tool for professor to manage courses and assignments and so on. The latest "Rails 4" branch of Expertiza, although combined with various enhancements from the past two years, is seriously broken, from data migration to key feature implementation. Part of the reason has been the design strategy and code changes by various teams.

Email notification feature to scheduled tasks

This is a feature that has already been partially implemented in Expertiza E1451 implemented both sychronous and asychoronous mailers. Sychronous Emails refer to the Emails sent immediatly after an event (e.g. when student receive a peer-review). Asychoronous Email we implemented by the Gem "delayed job” and when a task (asychronous Email) is added to the delayed queue, a count-down number of minutes needs to be specified.

Our team aims to extend this project. This wiki page documents the problem analysis and provides a guideline for future development and enhancement.

Scope

Project Scope

E1451. ​Create Mailers for All Email Messages github wiki report (Merged in E1483)

Extending this project, the new system should be capable of

• If one task is added to the delayed job queue, the asychronous Email should be updated or deleted automatically.
• Add UI to visualize for the task in delayed job queue, instructors should be able to view tasks related to the assignments they have created.
• Keep log of the scheduled tasks when they are scheduled and done, record events in the same log as project E​1478.
• [optional] support more scheduled task:
  • instructors are able to schedule the time to drop all the outstanding reviews (reviews which has not been started)
  • instructors are able to schedule a specific time to send Emails to all the assignment participants who are still not in any team to find or form one.
  • (new) instructor should be able to schedule a time to drop all the topics which are held by 1 person teams.
• create tests to make sure the test coverage increases.

Files Involved

Mailers:

• delayed_mailer.rb

Models:

• assignment_form.rb
• due_date.rb
• delayed_job.rb(new created)
• scheduled_task.rb(new created)

Views:

• _due_dates.html.erb
• _assignments_actions.html.erb
• scheduled_jobs.erb(new created)

Controllers:

• assignments_controller.rb

Gems Related

• gem 'delayed_job_active_record'

Delayed:Job encapsulates the common pattern of asynchronously executing longer tasks in the background<ref> Delayed_job Gem</ref>. It allows to support multiple backends for storing the job queue. By using 'delayed_job_active_record' gem, we can use delayed_job with Active Record. This Active Record backend requires a job table. After running rails generate delayed_job:active_record and rake db:migrate, a "delayed_jobs" table is created in our database. This gem integrates well with many RDBMS backend such as MySQL.

• gem 'paper_trail'

Problem Analysis

Time Issues

Initially, when we want to verify the email function, we found many time issues in this system. That blocks our work about email notification. Some related problems are explained and analyzed in this section.

Wrong displayed time

Firstly, when we set a due time to test the mail features, we found the display of time is incorrect.

In the “Assignment Edit”->“Due dates”, when we modify the “Date & time” of the deadline, the displayed time will be 4 hours ahead of the time we saved.

Set due time

After we click the save button, we can see that all the time are 4 hours ahead of the set time

The deadline time is stored correct in the database

After several tries, we found that every time when we click "save", the saved time is 4 hours earlier then the last saved time. However, the time in the database is alway correct as the time we save. After we analyze, we found the problem may lay in the line of 68 of views/assignment/edit/_due_dates.html.erb file.

due_at = new Date(due_at.substr(0, 16)).format('yyyy/mm/dd HH:MM');

When we declare a Data object, this Data() function will perform a time zone conversion automatically. Yet Rails’ default timezone stored in database is UTC. So the displayed time(local time, which is EDT) and time in database is different.

Different time zone

In the previous version, when current time is compared with the time stored in database, they may apply to different time zones so that the result of comparison may be wrong.
When we delay a deadline of an assignment, for example, we set the deadline of metareview from2015/03/28 16:00 to 2015/04/04 20:00 and set the reminder hr to 16 hours.

After click "save", the run time showed database is about 8:00 am. Since 20-16=4, the correct run time is 4:00 am.

The reason why there is a four-hour time difference is generated from the file application_form.rb, method find_min_from_now(due_at), and line 142 time_in_min=((due_at - curr_time).to_i/60). due_at is the system time for Rails (UTC), while curr_time is the local time which is EDT. The two time zones have four-hour time difference.

New deadline replace the old one

This time, we add a new delay in Review section, we delay the deadline from 2015/03/22 21:00 to 2015/03/30 21:00, and set the remind hr to 8 hours.

However, the delayed_jobs database form is still the same, which means in one assignment there is only one reminder can work.
As a result, we conclude that only one due_time record associated with different period exists in the database:

• In Expertiza, one assignment has several period, such as submission, review, metareview. Administrates are able to set and postpone due dates for each period separately.
• In the previous version, when the instructor postpone the review deadline and then postpone the submit deadline, the submit deadline’s modification will replace the the review deadline’s modification in database.
• In this case, if both of them need Email reminder, there will be no Email about the former modified deadline.
• After our analysis, we found the due time object is identified with assignment_id, instead of deadline type id.

UI issues

In the previous version, there is no UI to display the reminders of assignments. There is no way for instructors to view their delayed tasks related to an assignment. We are going to add a button under Assignment->edit, and add a view to display all delayed jobs derived from the delayed_jobs table in our database.

System Design

Fix Time Issues

Unified time zone

We can convert current time to the same time zone as the deadline stored in database. Then the result of comparison will be right so that it can be used for further usage.

Separate deadline of each topic period

In each Assignment, each deadline type (E.g review, submit, metareview) should has its own Email reminder time in the database. New postponed deadline of one type can only replace the same deadline type in the same assignment id category.

Add UI to visualize for scheduled tasks

In the UI module, we are going to display the scheduled time for reminder emails of submit, review and final review. And when reminder or due date are modified, the displayed content will also be changed.

support more schedule tasks

In the Assignment Edit page->Due dates:

• When we set the review’s due date, create a “delayed job” at the same time. When the review is due, it will automatically find all the outstanding reviews (reviews which have not been started) in the database then delete them.
• Add a new teamup deadline, set up a reminder and create a “delayed job” at the same time. When “delayed job” is triggered, it will automatically find all the assignment participants who are still not in any team in the database, and send Emails to them to find teammate.
• When teamup time is due, the system will find all the topics which are held by 1 person teams in the database, then the professor can drop those topics.

The design we want to highlight here is that these additional scheduled tasks can be achieved in same way as email notification used. The difference is that each task refers to a different related due time(either a previously existing one or a new created one). Then they all set up a reminder and create a “delayed job” at the same time. When “delayed job” is triggered, corresponding actions could be taken.

Support more scheduled tasks

Diagram description: In our system, we would have four scheduled time: submission, review, metareview and team_up. When due time comes, the system takes corresponding actions described as above. These scheduled actions are called scheduled tasks. And the design to achieve these functions are explained above. This diagram just displays the text description above in "Support more scheduled tasks " section.

References

<references/>