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 for 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