CSC/ECE 517 Spring 2017/E1732 Additions to logging
Introduction
Currently, Expertiza doesn’t log anything, beyond the events in the console log. But often there is a need to know when a student logged in, reserved a topic, dropped off a team, reviewed etc. In real time, logs are the first thing to start checking the performance and other metrics. But it is also important to describe which data to log and why. Users activity may not be used for testing or debugging purposes, but can help an evaluator or admin to make sure the authenticity of student submissions and check the timelines. It sure can be used in future to read those logs and report back to users about their action timeline if required.
What to Log
For Students
- Logins, logouts, signups
- submission of files/links
- issuing invitations, joining teams, dropping off teams
- requesting reviews, submitting reviews
- undoing any of these operations.
For Admin/ Instructor/ TA
- creating/editing courses and assignments
- giving grades
- impersonating other users
- adding TAs, adding participants to courses or assignments
- assigning reviewers.
What we plan to implement
The project mainly consists of two parts:
1. Logging the various students and instructors logs and process them accordingly.
2. Extend the existing UI or create one separately if needed along with the required fields as described in the project description.
The same has been mentioned in terms of a flowchart:
Design of Task 1: Activity Logger
This same project was assigned to another team last semester and a lot of code was written to log the given accounts. A lot of additions were added to many controllers wherever the events are to be tracked. The code was not merged anyways. We came up with an idea that doesn't modify or add any code to controllers. Logging model shouldn't be a burden to the UI at all.
Public Activity Gem The gem we used is
gem 'public_activity'
According to the documentation:
Public_activity provides easy activity tracking for your ActiveRecord, Mongoid 3 and MongoMapper models in Rails 3. Simply put: it records what has been changed or created and gives you the ability to present those recorded activities to users - in a similar way to how GitHub does it.
This gem perfectly solves our objectives in two ways.
- It tracks our events because every event type we need to address has some change or access models.
- No modifying or adding code in controllers. (Except some session logins and logouts need to be added)
Design of Task 2: UI Part
We need to read the activities based on the search options added and put onto the user interface to make anyone view based on the filter they provide. Filters include user name, from time and to time. The look of the UI part would be a simple view that contains
- User : {Textbox}
- Date From: {Date Filler}
- Date to: {Date Filler}
The results after the querying would be populated in grid that makes it easy to observe
Implementation of Task 1: Logging
Changes to the database
We plan to create a new table in the database for storing these activities. A new migration needs to be created to add the new table to the database.
New model
A new model will be created to add each log to the activity. The model will contain fields pertaining to a model such as a user id, type of event, event description, timestamp etc.
Table: Event logs
| Element | Type |
|---|---|
| trackable_id | Integer |
| trackable_type | varchar |
| owner_id | Integer |
| owner_type | varchar |
| created_at | Datetime |
| updated_at | Datetime |
| parameters | text |
Add Public Activity to Model
How to add to a model?
include PublicActivity::Model
tracked owner: ->(controller, _model) { controller && controller.current_user }
This small piece of code ensures all the activities are noted when there is an entry made or changed or deleted
We added to the following models:
- assignment.rb
- assignment_due_date.rb
- assignment_participant.rb
- assignment_questionnaire.rb
- course.rb
- course_participant.rb
- invitation.rb
- join_team_request.rb
- participant.rb
- response.rb
- response_map.rb
- review_grade.rb
- sign_up_sheet.rb
- teams_user.rb
- user.rb
Controllers that were modified, since some activities don't have any effect on a model to enable public activity record those events.
- activities
- application
- auth
- course
- impersonate
Implementation of Task 2: UI
New Views
Public Activity records the events with a trackable id, the table on which the action took place but not any details or description. We add to the public activities views the required code to get the details with the trackable id, type, model taken as parameters. All the activity views specific to each event are added under public activity folder specific to each model.
We added the specific filters such as search by user name or any specific date to search for the events. By default, all the activities are shown up on the page accessed with the link "activities/index"
Future Work - Testing
- Model Testing: Since we are adding a new database table, we need to test Rails model with Rspec that checks if the validations are working fine such as it "is valid with valid attributes", it "is not valid without a user", it "is not valid without an event", it "is not valid without a timestamp"
- Controller Testing: Design includes the addition of a controller that takes care of storing the logs and then loading them up to fill the views if queried which requires a lot of testing. The tests include
- For each event, check if the respective method in the respective controller is called
- For each event, an entry is being correctly stored in the database
- A feature test that checks the UI part of the flow that includes Capybara mocking the admin fills the query page and the testing whether the results are viewed correctly