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: Logging

The Logger class in Rails has the following severity levels:

• UNKNOWN - An unknown message that should always be logged.
• FATAL - A un-handleable error that results in a program crash.
• ERROR - A handleable error condition.
• WARN - A warning.
• INFO - Generic (useful) information about system operation.
• DEBUG - Low-level information for developers.

Usually, in a production system Logger is set to INFO or WARN. For our project, we plan to use DEBUG level severity. For this, we first need to change the Formatter class to include DEBUG level severity to the log file.

We plan to implement a new helper file which deals logging the events which we want. We plan on doing it this way to separate out the logging code from the controller code.

Design of Task 2: UI Part

We nee to read the log data and put onto the user interface to make anyone view based on the filter they provide. Filters include user name, event type, 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}
• Event Type: {Drop Down box}

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 logging. 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 record. 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
user_id	Integer
start_date	Datetime
event_type	String
event_description	String
user_role	Integer

New helpers

A new helper file will be created which will take care of what events to log.

Implementation of Task 2: UI

New Views

A new view will be added which can be accessed only by the system admins which shows the admins the list of logs. A log entry will have a user id with whom the event is associated to, an event type, a description of the event and a timestamp. We will give the admin the option to filter the logs based on each of the mentioned values. Options to add multiple search criteria will also be provided.

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

References

1. Expertiza on GitHub
2. The live Expertiza website
3. Expertiza project documentation wiki
4. Severity level in Logger