CSC/ECE 517 Spring 2017/E1732 Additions to logging - Revision history

Rmandav: /* Testing */

2017-05-09T19:22:42Z

Testing

← Older revision		Revision as of 19:22, 9 May 2017
Line 144:		Line 144:
	[[File:ac22.png]]		[[File:ac22.png]]

	== Testing ==		== Future Work - Testing ==

	<br>		<br>

Rmandav: /* New Views */

2017-05-09T19:22:09Z

New Views

← Older revision		Revision as of 19:22, 9 May 2017
Line 138:		Line 138:

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

			[[File:ac12.png]]


			[[File:ac22.png]]

	== Testing ==		== Testing ==

Rmandav: /* Implementation of Task 2: UI */

2017-05-09T19:05:28Z

Implementation of Task 2: UI

← Older revision		Revision as of 19:05, 9 May 2017
Line 134:		Line 134:
	====New Views====		====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~~.		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.
			<br>

	~~[[File:LogToGUI~~.~~png]]~~		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"

	== Testing ==		== Testing ==

Rmandav at 18:51, 9 May 2017

2017-05-09T18:51:08Z

@@ Line 45: / Line 45: @@
 * 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 ==
@@ Line 93: / Line 94: @@
 |}
 == Implementation of Task 2: UI ==

Rmandav: /* Implementation of Task 1: Logging */

2017-05-09T16:08:23Z

Implementation of Task 1: Logging

← Older revision		Revision as of 16:08, 9 May 2017
Line 59:		Line 59:
	====Changes to the database ====		====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.		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====		====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.		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'''		'''Table: Event logs'''
Line 71:		Line 71:
	! Type		! Type
	\|-		\|-
	\| ~~user_id~~		\| trackable_id
	\| Integer		\| Integer
	\|-		\|-
	\| ~~start_date~~		\| trackable_type
			\| varchar
			\|-
			\| owner_id
			\| Integer
			\|-
			\| owner_type
			\| varchar
			\|-
			\| created_at
	\| Datetime		\| Datetime
	\|-		\|-
	\| ~~event_type~~		\| updated_at
	\| ~~String~~		\| Datetime
	\|-		\|-
	\| ~~event_description~~		\| parameters
	\| ~~String~~		\| text
	\|-
	~~\| user_role~~
	~~\| Integer~~
	\|}		\|}

	~~====New helpers====~~

	~~A new helper file will be created which will take care of what events to log.~~
	~~[[File:UML AddEventLogger.png]]~~
	== Implementation of Task 2: UI ==		== Implementation of Task 2: UI ==

Rmandav: /* Design of Task 2: UI Part */

2017-05-09T15:59:47Z

Design of Task 2: UI Part

← Older revision		Revision as of 15:59, 9 May 2017
Line 47:		Line 47:

	== Design of Task 2: UI Part ==		== 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.		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		The look of the UI part would be a simple view that contains
	* User : {Textbox}		* User : {Textbox}
	* Date From: {Date Filler}		* Date From: {Date Filler}
	* Date to: {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		The results after the querying would be populated in grid that makes it easy to observe

Rmandav: /* Design of Task 1: Activity Logger */

2017-05-09T15:57:13Z

Design of Task 1: Activity Logger

← Older revision		Revision as of 15:57, 9 May 2017
Line 43:		Line 43:

	This gem perfectly solves our objectives in two ways.		This gem perfectly solves our objectives in two ways.
	1) It tracks our events because every event type we need to address has some change or access models.		* It tracks our events because every event type we need to address has some change or access models.
	2) No modifying or adding code in controllers. (Except some session logins and logouts need to be added)		* No modifying or adding code in controllers. (Except some session logins and logouts need to be added)

	== Design of Task 2: UI Part ==		== Design of Task 2: UI Part ==

Rmandav: /* Design of Task 1: Logging */

2017-05-09T15:56:45Z

Design of Task 1: Logging

← Older revision		Revision as of 15:56, 9 May 2017
Line 30:		Line 30:
	[[File:flow.jpg]]		[[File:flow.jpg]]

	== Design of Task 1: ~~Logging~~ ==		== Design of Task 1: Activity Logger ==

	The ~~Logger class in Rails has~~ the ~~following severity levels:~~		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.
			<br>

	* UNKNOWN - An unknown message that should always be logged.		'''Public Activity Gem'''
	* FATAL - A un-handleable error that results in a program crash.		The gem we used is
	* ERROR - A handleable error condition.		<pre> gem 'public_activity' </pre>
	* 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~~.		According to the documentation: <br>
			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.

	~~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.		This gem perfectly solves our objectives in two ways.
			1) It tracks our events because every event type we need to address has some change or access models.
			2) No modifying or adding code in controllers. (Except some session logins and logouts need to be added)

	== Design of Task 2: UI Part ==		== Design of Task 2: UI Part ==

Rmandav: /* New Views */

2017-04-13T03:44:46Z

New Views

← Older revision		Revision as of 03:44, 13 April 2017
Line 96:		Line 96:

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

			[[File:LogToGUI.png]]

	== Testing ==		== Testing ==

Rmandav: UML added

2017-04-13T03:42:03Z

UML added

← Older revision		Revision as of 03:42, 13 April 2017
Line 90:		Line 90:

	A new helper file will be created which will take care of what events to log.		A new helper file will be created which will take care of what events to log.
			[[File:UML AddEventLogger.png]]
	== Implementation of Task 2: UI ==		== Implementation of Task 2: UI ==