CSC/ECE 517 Fall 2014/OSS E1451 las

From Expertiza_Wiki
Jump to navigation Jump to search

E1451 - Create Mailers for All Email Messages

Introduction

Expertiza<ref name="expertiza>Expertiza http://wikis.lib.ncsu.edu/index.php/Expertiza</ref>, an open source web application designed to carry out multiple peer review processes for learning and education purpose, has been used by CSC517 Object Oriented Programming Languages and Systems course at NC State University as the main project management tool. 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. The Expertiza Emailer team, consisting of three students, aims to restore the e-mailer and e-mail messages capability from Projects E701 and E729, and bring back the new features created by Project E916. Significant amount of time has been spent on correcting bugs and errors in the program before the email features can be restored, and therefore this wiki also documents the changes our team has made and provides a guideline for future development and enhancement.

Project Requirements

1. Restore features and functions in Expertiza that trigger email messages

2. Create mailers for all email messages for both asynchronous events and synchronous events

3. All emails should be sent via ActionMailer

4. Emails should have different class

Modification to Existing Code

Data migration issue

The database migration issue occurs when carrying out "rake db:migrate" command. We found the mirrored image from the existing database still has incorrect table fields. The problem may not appear until later during feature testing. Therefore, our team decided to fix the data migration issues from ground up. In total, more than 36 files have been fixed. Most of them are database migration files. To eliminate future table creation issues with mysql2 gem, we have also changed the integer byte length of MySQL tables from 10 to 8 and have revised the SQL query methods inside the migration files to improve efficiency. The methods missing from the models directory related to site_controller have been restored for controller_action, menu_item, permission, role, and site_controller models.

Assignment Controller

Two types of events will trigger email messages. One is synchronous event; the other is asynchronous event. The synchronous events refer to activities of reviewers and authors. For example, each email should be sent when work has been reviewed; a feedback to the review has been posted; meta review comments, and social bookmark have been added. In addition, when a user is cleared from the waiting list the party should be notified. Our next task is to restore the assignment features in order to examine the asynchronous events. Asynchronous events are a serious of time events. Due to the bugs in views and partials files under the assignment edit page, each due date for submission, review, meta review, sign up, and drop topic is missing. The JavaScript implementation is done via JQuery gem. After the JavaScript has been fixed, now the correct due dates are displayed correctly.

The following changes have been made:

1. All *.rhtml files in app/views/bookmarks have been renamed to *.html.erb for compatibly reason.

2. The following lines have been added to Gemfile

   gem 'jquery-datetimepicker-rails'
   gem 'graphr'
   gem 'daemons'

3. The following parsing errors in app/controllers/assignment_controller.rb have been corrected.

Original:

   duatedates[i].due_date(:db).to_s

Changed:

   duatedates[i].due_date.to_s(:db)

4. The following code in ap/views/assignments/edit/_rubrics.html.erb has been changed.

Original:

   <%= questionnaire(@assignment, 'ReviewQuestionnaire').to_json.html_safe %>.review_questionnaire
   <%= assignment_questionnaire(@assignment, 'ReviewQuestionnaire').to_json.html_safe %>.assignment_questionnaire

Changed:

   <%= questionnaire(@assignment, 'ReviewQuestionnaire').to_json.html_safe %>
   <%= assignment_questionnaire(@assignment, 'ReviewQuestionnaire').to_json.html_safe %>

Synchronous Emailer

All of synchronous events are triggered by controllers and the call is made to app/mailers/mailer.rb (formally as model in /app/models/) via the sync_message() method call. Here mailer.rb extends ActionMailer class. Because part of the email implementation was done on Rails 3 platform, to make it compatible for Rails 4, revision has been made. The required email template has been added for both generic_message and sync_message method calls. Here is an example of synchronous event email that simulates an event when the work you reviewed before has been revised.

1. app/models/mailer.rb has been moved to app/mailers/mailer.rb

2. Two view templates have been added to app/views/mailer directory. They are sync_message.html.erb and sync_message.text.erb

    <!DOCTYPE html>
    <html>
    <head>
      <meta content='text/html; charset=UTF-8' http-equiv='Content-Type' />
    </head>
    <body>
    <%= render :partial => 'mailer/partials/'+@partial_name+'_html' %>

    <hr>

    This message has been generated by <A HREF="http://expertiza.ncsu.edu">Expertiza</A><BR/>
    http://expertiza.ncsu.edu

    </body>
    </html>

3. Correct DOCTYPE and html codes have been added to app/views/mailer/generic_message.html.erb

4. The following line in the sync_message(defn) method has been comment out from app/mailers/mailer.rb in order to encode email correctly.

   content_type: "text/html"

5. The following method calls in the following files have been changed.

a) app/controllers/grades_controller.rb
b) app/models/courses_users.rb
c) app/models/participant.rb

Original:

   Mailer.deliver_message(

Changed:

   Mailer.sync_message(

Asynchronous Emailer

The asynchronous emailer is controlled by Delayed::Job class and a daemon gem must be activated to carry out the task. All events are called to /app/emailers/delayed_mailer.rb via one of the following methods: email_reminder(), mail_assignment_participants(), mail_reviewers(), mail_metareivewers(), getTeamMembersMail(), and mail_signed_up_users(). The DelayedMailer class acts as a wrapper class to the Mailer class in the /app/mailers/mailer.rb via the delayed_message() method call. These events are added to the queue by Delayed::Job.enqueue() command. Each event as record is stored in the delayed_job table, which can be browsed on RubyMine. Because all of the asynchronous events are controlled by the assignment controller, events are triggered by the add_to_delayed_queue() method. Each time when an assignment is updated or saved, event queues are refreshed. We found this is not very efficient but it has worked as expected.

RSpec test cases

To test the emailer features, we have restored RSpec test cases for both delayed_mailer.rb (asynchronous maier) and mailer.rb (synchronous mailer). Because the existing RSpec files were developed in RSpec 2.x, upgrade is required. Ideally, the files in /test/fixtures should be used to populate the test data for RSpec, and therefore we did not restore all the files in /spec/fixtures/ directory. Currently, the fixture files are not completed and loading them into the test database may cause failure for the test, so we recommend to comment out the following line in the /spec/rails_helper.rb

   #config.global_fixtures = :all

Future developers must take extreme care to make sure all fixture files work before enable this option.

1. Two files have been added spec/ directory:

a) spec/integration/delayed_mailer_spec.rb
b) spec/models/mailer_spec.rb

The following code has been added to each test case:

   Delayed::Job.delete_all

2. The following code has been added to spec/rails_helper.rb in order for the RSpec to pass the test.

   ENV["RAILS_ENV"] ||= 'test'
   require File.expand_path("../../config/environment", __FILE__)
   require 'rspec/rails'
   require 'rspec/autorun'
   require 'capybara/rspec'
   require 'capybara/rails'

Installation Steps

Because asynchronous events require a daemon running in the background and the new Delayed Job for Rails 4 has additional fields, the following steps are recommended.

1. Install Expertiza and execute 'bundle install'

2. Create database and perform data migration using 'rake db:migrate'

3. Execute 'rails generate delayed_job:active_record' at the prompt. This will create a delalyed_job file in /bin directory.

4. Execute 'rails generate delayed:upgrade' if delayed_job has been created before.

5. Start the delayed_job server by executing

    RAILS_ENV=production bin/delayed_job start

Known Issues and Future Work

1. The due date for signup activity may not display correctly. To refresh, users must click the "review round" button or the "save" button again.

2. Each time when an assignment is saved all delayed_job tasks will be deleted and refreshed even if the dates have not been changed. This may not be very efficiency and may cause problems in the future. Checking mechanism should be built in to verify if any date has been changed.

3. DateTimePicker field could be accidently changed by mouse click.

4. Prioritization in the Delayed Job function in case of multiple email load

5. Extending functionality to include Weekly/Monthly digest that can consist of users WebAssign summary.

6. In-built messaging (Inbox, Sent, Draft etc.) functionality in addition to email for easy tracking of outgoing and incoming messages.

References

<references/>