CSC/ECE 517 Fall 2016/E1686-Timestamps for students' submissions

Problem Statement

In this project, We will keep track of timestamp records for students' submissions and updates of artifacts (links to google doc/wikipedia/github), reviewers' submissions and edits of peer-reviews and author feedbacks.We will also create a timeline view for each artifact, showing when it was submitted/resubmitted and when it was reviewed. With our work, users (students and instructors) can see:

• when do the authors submit and update their artifacts.
• when do reviewers submit peer-reviews.
• when do reviewees send author feedback.
• when do reviewers update their peer reviews.

Approach

From a perspective (both instructors and students), users should be able to see such a timeline with all the events for each submission of an assignment. The events can be -

• add/edit events of various submission links/files
• Reviews
• author feedbacks
• peer reviews

Each of these artifacts can be edited and updated multiple times. Because we want to track when these artifacts are updated, we have to store their information in the database. We use the table suggested in the problem description “submission_histories”-

• Id :: integer- primary key for this table.
• team_id :: integer ← foreign key to the teams table
• submitted_detail :: string ← details of the event. This can be one of x values.
  • Link - if it is a assignment submission link. This can further be of 4 types -
  • Google Docs
  • Wikipedia
  • Github repository
  • Any other web link
• Review ids - if the event is a review submission
• Author feedback id - if the event is an add or edit operation on author feedback.
• Peer review id - if the event is an add or edit operation on peer review.
• Submitted_at  :: datetime ← to store the timestamp of the event
• Type :: string ← field which distinguish between different types of events - to be used for polymorphism.
• Action :: string - add / edit / delete based on the event.

These are the common components under which each component in the timeline can be classified. Each of these components are explained in detail on how it fits into the timeline and its significance and types listed.

Data stored in submission_histories table

• Google Document, Wikipedia article, Github repository url : All of these are types of links given by the team during their submission. Through the url, we will identify which type of a submission is this, and then create an object of the particular class using the factory pattern. Each of these classes will implement their own “getLastUpdatedTimestamp” method, using the suggested APIs, through which we can get the required timestamp.
• File path and any other web link - These are also a part of main submissions, but since there is no way of tracking changes to these artifacts, we just take the time of the system when the link is added or removed.
• Peer Reviews, Author feedback: Peer reviews and author feedbacks are updated into the submission history table for every edit that takes place. The “updated_at” field acts as the current timestamp for edits in the Peer Reviews and Author feedbacks and the “created_at” field marks the start of these Events.

Data retrieved from existing tables

• Reviews: Timestamp for assignment reviews are taken from “responses” and “response_maps” table. The responses table contains round field and when “is_submitted” flag is true, the submission appears on the reviewee timeline where the “reviewee_id” retrieved from response_maps table. The reviews attached to the respective reviewee are collected and updated_at field gives the submission timestamp which is used on the timeline. Each review is collected and is added to the single Event map.
• Timeline Parameters: Values corresponding to an assignment which are common for a given Assignment are retrieved from the assignments table. And the timeline parameters are obtained by calculating from the created_at which is the start date for the assignment and the field rounds_of_reviews determines the deadline by adding up the value stored in days_between_submission field of the same table. The Events - Start Date, Submission Deadline and Revision Deadline and Final assignment deadline exists for each assignment.

All the components are then added into one single map - Event -> Timestamp which is sorted on timestamp values and is displayed on screen.

Files Added/Modified

Models

• assignment

require 'rufus-scheduler'

• files_submission_history
• github_pull_request_submission_history
• github_repo_submission_history
• github_submission_history
• googledoc_submission_history
• link_submission_history
• submission_history
• wikipedia_submission_history

Controllers

• submitted_content_controller

Views

• submitted_content/_main.html.erb
• submitted_content/_submission_history.html.erb

spec

• models/github_repo_submission_history_spec.rb
• models/link_submission_history_spec.rb
• models/submission_history_spec.rb
• models/wikipedia_submission_history_spec.rb

+require "rails_helper"
+
+describe WikipediaSubmissionHistory do
+  describe "get_submitted_at_time" do
+    it "should return the last time a wiki page was updated" do
+      history_object = WikipediaSubmissionHistory.new
+      time_stamp = history_object.get_submitted_at_time("http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2016/oss_E1663")
+      expect(time_stamp).not_to be_empty
+    end
+  end
+end

Factory Pattern We are planning to use factory pattern for the type of link submitted. We will create an interface Type then we will create individual concrete classes like GitHubLink, GoogleDocLink, WikiLink which will implement our Type interface. To use factory pattern we will define TypeFactory class which will have static getType method that returns a Type that depends on the criteria that has been supplied.

UML Diagram:

Testing Plan:

• Unit Testing of controllers

This involves unit testing of following controllers: TeamsController, because we will have to change some methods.

• Unit Testing of Models

This involves writing rspec test for all the newly created models like submission_history, google_doc_submission_history, etc. Tests for team model are already written.

• UI Testing
  • Login as student/instructor.
  • Go to Assignments Home Page.
  • Here you will find a timeline with several tags like submission, review, resubmission, rereview.
  • Also, There will be a tags for the authors submitting and updating their artifacts, reviewers submitting peer-reviews, reviewees sending author feedback and reviewers updating their peer reviews.
  • As UI would be modified a lot, more testing part would be added after the implementation.

References

• https://www.tutorialspoint.com/design_pattern/factory_pattern.htm
• https://developers.google.com/drive/v3/web/quickstart/ruby
• https://www.mediawiki.org/wiki/API:Main_page
• https://github.com/octokit/octokit.rb
• https://github.com/piotrmurach/github

Doubts: Significance of submission record table