Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-05-09T19:22:42Z

Rmandav: /* Testing */

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

[[File:flow.jpg]]

== 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
<pre> gem 'public_activity' </pre>

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

{| class="wikitable"
|-
! 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?
<pre>
include PublicActivity::Model
tracked owner: ->(controller, _model) { controller && controller.current_user }
</pre>

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"

[[File:ac12.png]]

[[File:ac22.png]]

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

== References ==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[http://ruby-doc.org/stdlib-2.1.0/libdoc/logger/rdoc/Logger.html Severity level in Logger]

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-05-09T19:22:09Z

Rmandav: /* New Views */

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

[[File:flow.jpg]]

== 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
<pre> gem 'public_activity' </pre>

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

{| class="wikitable"
|-
! 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?
<pre>
include PublicActivity::Model
tracked owner: ->(controller, _model) { controller && controller.current_user }
</pre>

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"

[[File:ac12.png]]

[[File:ac22.png]]

== 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 ==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[http://ruby-doc.org/stdlib-2.1.0/libdoc/logger/rdoc/Logger.html Severity level in Logger]

File:Ac22.png

2017-05-09T19:21:47Z

Rmandav:

File:Ac12.png

2017-05-09T19:19:32Z

Rmandav:

File:Ac2.jpg

2017-05-09T19:10:54Z

Rmandav:

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-05-09T19:05:28Z

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

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

[[File:flow.jpg]]

== 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
<pre> gem 'public_activity' </pre>

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

{| class="wikitable"
|-
! 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?
<pre>
include PublicActivity::Model
tracked owner: ->(controller, _model) { controller && controller.current_user }
</pre>

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"

== 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 ==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[http://ruby-doc.org/stdlib-2.1.0/libdoc/logger/rdoc/Logger.html Severity level in Logger]

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-05-09T18:51:08Z

Rmandav:

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

[[File:flow.jpg]]

== 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
<pre> gem 'public_activity' </pre>

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

{| class="wikitable"
|-
! 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?
<pre>
include PublicActivity::Model
tracked owner: ->(controller, _model) { controller && controller.current_user }
</pre>

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

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

 
* '''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 ==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[http://ruby-doc.org/stdlib-2.1.0/libdoc/logger/rdoc/Logger.html Severity level in Logger]

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-05-09T16:08:23Z

Rmandav: /* Implementation of Task 1: 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:

[[File:flow.jpg]]

== 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
<pre> gem 'public_activity' </pre>

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

{| class="wikitable"
|-
! Element
! Type
|-
| trackable_id
| Integer
|-
| trackable_type
| varchar
|-
| owner_id
| Integer
|-
| owner_type
| varchar
|-
| created_at
| Datetime
|-
| updated_at
| Datetime
|-
| parameters
| text

|}

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

[[File:LogToGUI.png]]

== 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 ==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[http://ruby-doc.org/stdlib-2.1.0/libdoc/logger/rdoc/Logger.html Severity level in Logger]

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-05-09T15:59:47Z

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

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

[[File:flow.jpg]]

== 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
<pre> gem 'public_activity' </pre>

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

{| class="wikitable"
|-
! 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.
[[File:UML AddEventLogger.png]]
== 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.

[[File:LogToGUI.png]]

== 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 ==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[http://ruby-doc.org/stdlib-2.1.0/libdoc/logger/rdoc/Logger.html Severity level in Logger]

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-05-09T15:57:13Z

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

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

[[File:flow.jpg]]

== 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
<pre> gem 'public_activity' </pre>

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

{| class="wikitable"
|-
! 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.
[[File:UML AddEventLogger.png]]
== 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.

[[File:LogToGUI.png]]

== 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 ==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[http://ruby-doc.org/stdlib-2.1.0/libdoc/logger/rdoc/Logger.html Severity level in Logger]

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-05-09T15:56:45Z

Rmandav: /* Design of Task 1: 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:

[[File:flow.jpg]]

== 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
<pre> gem 'public_activity' </pre>

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

{| class="wikitable"
|-
! 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.
[[File:UML AddEventLogger.png]]
== 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.

[[File:LogToGUI.png]]

== 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 ==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[http://ruby-doc.org/stdlib-2.1.0/libdoc/logger/rdoc/Logger.html Severity level in Logger]

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-04-13T03:44:46Z

Rmandav: /* New Views */

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

[[File:flow.jpg]]

== 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'''

{| class="wikitable"
|-
! 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.
[[File:UML AddEventLogger.png]]
== 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.

[[File:LogToGUI.png]]

== 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 ==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[http://ruby-doc.org/stdlib-2.1.0/libdoc/logger/rdoc/Logger.html Severity level in Logger]

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-04-13T03:42:03Z

Rmandav: UML added

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

[[File:flow.jpg]]

== 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'''

{| class="wikitable"
|-
! 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.
[[File:UML AddEventLogger.png]]
== 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 ==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[http://ruby-doc.org/stdlib-2.1.0/libdoc/logger/rdoc/Logger.html Severity level in Logger]

File:UML AddEventLogger.png

2017-04-13T03:40:08Z

Rmandav:

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-04-13T02:46:15Z

Rmandav: /* Changes to the database */

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

[[File:flow.jpg]]

== 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'''

{| class="wikitable"
|-
! 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 ==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[http://ruby-doc.org/stdlib-2.1.0/libdoc/logger/rdoc/Logger.html Severity level in Logger]

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-04-13T02:45:53Z

Rmandav: /* New models */

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

[[File:flow.jpg]]

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

'''Table: Event logs'''

{| class="wikitable"
|-
! 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 ==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[http://ruby-doc.org/stdlib-2.1.0/libdoc/logger/rdoc/Logger.html Severity level in Logger]

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-04-08T03:53:21Z

Rmandav: /* Testing */

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-04-08T03:52:51Z

Rmandav: Testing part added

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-04-08T03:32:25Z

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

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-04-08T03:28:11Z

Rmandav: Design of part 2 added

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-04-08T01:29:56Z

Rmandav: /* What to Log */

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-04-08T01:25:54Z

Rmandav: What to log added

CSC/ECE 517 Spring 2017/E1732 Additions to logging

2017-04-08T01:23:45Z

Rmandav: Introduction Added

CSC/ECE 517 Spring 2017/oss E1712

2017-04-01T05:03:46Z

Rmandav: /* Testing */

== Introduction ==
This project is part of an educational web application called Expertiza. This wiki gives the details on the refactoring tasks undertaken as part of continuous improvement of Expertiza.

===Background===
[[Expertiza_documentation|Expertiza]] is an open source project managed by the faculty and students of NCSU. It is a web application which offers a platform for assignments and allows learning through peer reviews.

===Motivation===
In the existing code the InvitationController and the JoinTeamRequestsController do the expected task but the there is a lot of redundancy and duplicity in the code, and the comments in the code are few and sparse. The aim of our project was to reduce the complexity of the controller by removing redundant code adding comments so that the code is easy to understand and all the variables used in the code are clearly explained.

==Current Implementation==
===Invitations Controller===
Invitations controller handles the functions required to send invitations out to potential teammates for a project. Once a student decides to invite someone into his assignment team the controller performs some checks before sending out the invitations. These checks are performed in the create function. The current implementation has a lot of redundant code and many nested if statements. The ABC size of the method is also very high. The controller also has functions which take care of cases where an invitee accepts/declines an invitation. There is also an option to retract a sent invitation which is handled by the cancel function in the controller.
====Tasks Identified====
* Rename to invitations_controller.rb, in accordance with current naming convention.
* The ABC size for create method is too high and needs to be refactored along by removing other nested if's in create and update_join_team_request methods.
* Use find_by instead of find_by_name and find_by_user_id_and_assignment_id.
* Add comments explaining what each method does, and comments on how important variables are used.
* Pending invitations needs to be displayed in the same format as other tables.
* Feature tests need to be written for the controller

===Join Team Requests Controller===
JoinTeamRequests controller deals with the actions to be performed after a student comes across an advertisement to join a project team. Whenever a project team creates an advertisement for others to join their team, students can see a link to the advertisement in the signup sheet. Once the student clicks on the link to the advertisement the student can then request to join the team. The create function in the JoinTeamRequestsController handles the checks before sending out the request. Again, the ABC size for this method is very high as there a lot of nested if conditions. Also, there is duplicate code in some of the functions in this controller which can be moved to a separate function.
====Tasks Identified====
* Add comments on why some important variables are used.
* The ABC size for create method is too high.
* Nested if's need to be refactored.
* Duplicate code needs to be removed.
* Pending join team requests needs to be displayed in the same format as other tables
* Feature tests need to be written for the controller
* Decline request is not working: Post route is not defined
* JoinTeamRequest.find(params[:id]. This retrieval is common to five methods which are :show, :edit, :update, :destroy, :decline. Can be put into private before action

==Change Specifics==
The tasks identified above were implemented and the details are given below.
===Invitations Controller===
* A new private function check_users was added which performs some basic checks before the create function is called. In the original implementation, there were a lot of nested if conditions which checked if a user is valid, is a participant in the project, and if the team has slots available. All these checks were the cause of the nested if statements because they needed to be checked before an invitation is sent out to a student. The nested if's were removed by moving all these checks into the private function thereby reducing the ABC size of the create method.
* Nested if statements in the update_join_team_request were removed by breaking the nested statements into separate conditions and using return when the condition fails. For example, when checking if the user is valid, instead of using a nested condition to check validity, if the user is not valid then we throw an error message and return from the function.
* Call to the method find_by_user_id_and_assignment_id has been replaced by find_by and passing the user_id and assignment_id as arguments to find_by. The code snippet showing the change made is shown below.
Before refactoring
<pre>AssignmentParticipant.find_by_user_id_and_assignment_id(inviter_user_id, assignment_id)</pre>
After refactoring
<pre>AssignmentParticipant.find_by(user_id: inviter_user_id, parent_id: assignment_id)</pre>
* Styling was added to the pending invitations table in accordance with the existing tables so that the view is uniform across the entire page.
* The name of the controller was changed in accordance with the current naming convention and comments were added explaining why some important variables were used and also giving more clarity to whoever wants to modify the code in the future. There were very few comments earlier and they did not explain much about what was going on in the functions.

===Join Team Requests Controller===
* A new private function check_team was added which takes most of the initial checks that are performed before a new join team request is successfully created. This significantly reduces the ABC size of the create method as almost all the conditional statements are moved to the private function which is called before the create function is called. The nested conditionals are also removed by making use of return statements just as in the invitations controller methods.
* The methods index, show and new all have code which is repeated. Another private function respond_after was written which makes the code DRYer.
* The view here too contained tables which did not follow the styling that is present throughout the other sections of the page. Styling was added to the pending join team requests table to make it same as the other tables.
* This controller had very comments and most of the variables were not explained, especially the codes used for reply_status which is used when a new request is sent and updated is not explained at all. The status codes 'A' - awaiting a reply etc. are clearly commented. Comments were also added explaining important pieces of code.
* POST route added to decline action in the routes file
* Common statement in show, edit, update, destroy, decline
Before refactoring
<pre> @join_team_request = JoinTeamRequest.find(params[:id]) </pre>
After refactoring
added private method find_request
<pre>
def find_request
@join_team_request = JoinTeamRequest.find(params[:id])
end
</pre>
Added before_action to the methods
<pre> before_action :find_request, only: [:show, :edit, :update, :destroy, :decline] </pre>

==Testing==
The below test cases written can be found at spec/features/invitation_check_spec.rb.

A student is initialised and an assignment is assigned to the student. This serves as a base for testing.
<pre>
@user1 = User.find_by(name: "student2064")
stub_current_user(@user1, @user1.role.name, @user1.role)
visit '/student_task/list'
# Assignment name
expect(page).to have_content('final2')

click_link 'final2'
expect(page).to have_content('Submit or Review work for final2')

click_link 'Signup sheet'
expect(page).to have_content('Signup sheet for final2 assignment')

# click Signup check button
@assignment_id = Assignment.first.id
visit "/sign_up_sheet/sign_up?id=#{@assignment_id}&topic_id=1"
expect(page).to have_content('Your topic(s): Hello world! ')

visit '/student_task/list'
expect(page).to have_content('final2')

click_link 'final2'
expect(page).to have_content('Submit or Review work for final2')

click_link 'Your team'
expect(page).to have_content('final2_Team1')

fill_in 'user_name', with: 'student2065'
click_button 'Invite'
expect(page).to have_content('Waiting for reply')
</pre>

===Test Cases===
====To invite a student with no topic====
<pre>
describe 'one student who signup for a topic should send an invitation to the other student who has no topic' do
before(:each) do
user = User.find_by(name: "student2065")
stub_current_user(user, user.role.name, user.role)
visit '/student_task/list'
expect(page).to have_content('final2')

click_link 'final2'
click_link 'Your team'
end

it 'is able to accept the invitation and form team' do
visit '/invitations/accept?inv_id=1&student_id=1&team_id=0'
visit '/student_teams/view?student_id=1'
expect(page).to have_content('Team Name: final2_Team1')
end

it 'is not able to form team on rejecting' do
visit '/invitations/decline?inv_id=1&student_id=1'
visit '/student_teams/view?student_id=1'
expect(page).to have_content('You no longer have a team!')
end
end
</pre>

====To invite a student with a topic====
<pre>
describe 'one student who has a topic sends an invitation to other student who also has a topic' do
before(:each) do
user = User.find_by(name: "student2065")
stub_current_user(user, user.role.name, user.role)
visit '/student_task/list'
expect(page).to have_content('final2')

click_link 'final2'
expect(page).to have_content('Submit or Review work for final2')

click_link 'Signup sheet'
expect(page).to have_content('Signup sheet for final2 assignment')

visit '/sign_up_sheet/sign_up?assignment_id=1&id=2'
visit '/student_task/list'
click_link 'final2'
click_link 'Your team'
end

it 'Student should accept the invitation sent by the other student and both have topics' do
visit '/invitations/accept?inv_id=1&student_id=1&team_id=2'
visit '/student_teams/view?student_id=1'
expect(page).to have_content('Team Name: final2_Team1')
end

it 'student should reject the invitation sent by the other student and both have topics' do
visit '/invitations/decline?inv_id=1&student_id=1'
visit '/student_teams/view?student_id=1'
expect(page).to have_content('Team Name: final2_Team2')
end
end
</pre>

====To retract an invitation====
<pre>
describe 'one student sends an invitation and retracts it' do
before(:each) do
visit '/student_task/list'
click_link 'final2'
click_link 'Your team'
end
it 'should remove entry from database' do
before_count = Invitation.count
click_link 'Retract'
expect(Invitation.count).to eq(before_count - 1)
end
end
</pre>

===Feature Test Scenarios===
Some of the possible test cases which can be used for the controllers are given below.

* Test for create method in invitations controller: Before sending out an invitation to another student there a lot of checks that need to be performed such as checking if the invitee is a valid user, if the student is a participant in the project etc. All these scenarios are tested and finally, we make sure that a new invitation has been created in the database. The image below gives a visual representation of all the checks performed before sending out an invitation.
[[File:InvitationCTest2.png | center]]

* Test for create method in join teams request controller: Similar to the create method in the invitations controller we need to do a lot of checks before sending out a new join team request. The below flow chart explains all the checks that need to be asserted before sending out a new request.
[[File:Test1.png|center]]

* Test for cancel method: The cancel method is called when the student who sends out an invitation wishes to retract the sent invitation. In this scenario the invitation is destroyed from the database and we assert that change by checking the change in the count of the database. The below diagram is attached for further clarity.
[[File:InvitationsCTest3.png | center ]]

* Test for decline method: In this test, we assert the change of reply_status to 'D' in the database.

Further improvements to this project would be to write feature tests for the scenarios discussed above.

== Running project remotely ==
VCL is used to host the project remotely. The login credentials as an instructor are "instructor6" with password "password". To log in as a student, you can use 'student5425' with password 'password'

http://152.46.20.227:3000

== References ==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/kira0992/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

CSC/ECE 517 Spring 2017/oss E1712

2017-04-01T04:19:47Z

Rmandav: /* Testing */

== Introduction ==
This project is part of an educational web application called Expertiza. This wiki gives the details on the refactoring tasks undertaken as part of continuous improvement of Expertiza.

===Background===
[[Expertiza_documentation|Expertiza]] is an open source project managed by the faculty and students of NCSU. It is a web application which offers a platform for assignments and allows learning through peer reviews.

===Motivation===
In the existing code the InvitationController and the JoinTeamRequestsController do the expected task but the there is a lot of redundancy and duplicity in the code, and the comments in the code are few and sparse. The aim of our project was to reduce the complexity of the controller by removing redundant code adding comments so that the code is easy to understand and all the variables used in the code are clearly explained.

==Current Implementation==
===Invitations Controller===
Invitations controller handles the functions required to send invitations out to potential teammates for a project. Once a student decides to invite someone into his assignment team the controller performs some checks before sending out the invitations. These checks are performed in the create function. The current implementation has a lot of redundant code and many nested if statements. The ABC size of the method is also very high. The controller also has functions which take care of cases where an invitee accepts/declines an invitation. There is also an option to retract a sent invitation which is handled by the cancel function in the controller.
====Tasks Identified====
* Rename to invitations_controller.rb, in accordance with current naming convention.
* The ABC size for create method is too high and needs to be refactored along by removing other nested if's in create and update_join_team_request methods.
* Use find_by instead of find_by_name and find_by_user_id_and_assignment_id.
* Add comments explaining what each method does, and comments on how important variables are used.
* Pending invitations needs to be displayed in the same format as other tables.
* Feature tests need to be written for the controller

===Join Team Requests Controller===
JoinTeamRequests controller deals with the actions to be performed after a student comes across an advertisement to join a project team. Whenever a project team creates an advertisement for others to join their team, students can see a link to the advertisement in the signup sheet. Once the student clicks on the link to the advertisement the student can then request to join the team. The create function in the JoinTeamRequestsController handles the checks before sending out the request. Again, the ABC size for this method is very high as there a lot of nested if conditions. Also, there is duplicate code in some of the functions in this controller which can be moved to a separate function.
====Tasks Identified====
* Add comments on why some important variables are used.
* The ABC size for create method is too high.
* Nested if's need to be refactored.
* Duplicate code needs to be removed.
* Pending join team requests needs to be displayed in the same format as other tables
* Feature tests need to be written for the controller
* Decline request is not working: Post route is not defined
* JoinTeamRequest.find(params[:id]. This retrieval is common to five methods which are :show, :edit, :update, :destroy, :decline. Can be put into private before action

==Change Specifics==
The tasks identified above were implemented and the details are given below.
===Invitations Controller===
* A new private function check_users was added which performs some basic checks before the create function is called. In the original implementation, there were a lot of nested if conditions which checked if a user is valid, is a participant in the project, and if the team has slots available. All these checks were the cause of the nested if statements because they needed to be checked before an invitation is sent out to a student. The nested if's were removed by moving all these checks into the private function thereby reducing the ABC size of the create method.
* Nested if statements in the update_join_team_request were removed by breaking the nested statements into separate conditions and using return when the condition fails. For example, when checking if the user is valid, instead of using a nested condition to check validity, if the user is not valid then we throw an error message and return from the function.
* Call to the method find_by_user_id_and_assignment_id has been replaced by find_by and passing the user_id and assignment_id as arguments to find_by. The code snippet showing the change made is shown below.
Before refactoring
<pre>AssignmentParticipant.find_by_user_id_and_assignment_id(inviter_user_id, assignment_id)</pre>
After refactoring
<pre>AssignmentParticipant.find_by(user_id: inviter_user_id, parent_id: assignment_id)</pre>
* Styling was added to the pending invitations table in accordance with the existing tables so that the view is uniform across the entire page.
* The name of the controller was changed in accordance with the current naming convention and comments were added explaining why some important variables were used and also giving more clarity to whoever wants to modify the code in the future. There were very few comments earlier and they did not explain much about what was going on in the functions.

===Join Team Requests Controller===
* A new private function check_team was added which takes most of the initial checks that are performed before a new join team request is successfully created. This significantly reduces the ABC size of the create method as almost all the conditional statements are moved to the private function which is called before the create function is called. The nested conditionals are also removed by making use of return statements just as in the invitations controller methods.
* The methods index, show and new all have code which is repeated. Another private function respond_after was written which makes the code DRYer.
* The view here too contained tables which did not follow the styling that is present throughout the other sections of the page. Styling was added to the pending join team requests table to make it same as the other tables.
* This controller had very comments and most of the variables were not explained, especially the codes used for reply_status which is used when a new request is sent and updated is not explained at all. The status codes 'A' - awaiting a reply etc. are clearly commented. Comments were also added explaining important pieces of code.
* POST route added to decline action in the routes file
* Common statement in show, edit, update, destroy, decline
Before refactoring
<pre> @join_team_request = JoinTeamRequest.find(params[:id]) </pre>
After refactoring
added private method find_request
<pre>
def find_request
@join_team_request = JoinTeamRequest.find(params[:id])
end
</pre>
Added before_action to the methods
<pre> before_action :find_request, only: [:show, :edit, :update, :destroy, :decline] </pre>

==Testing==
The below test cases written can be found at spec/features/invitation_check_spec.rb. To run: $rspec spec/features/invitation_check_spec.rb

A student is initialised and an assignment is assigned to the student. This serves as a base for testing.
<pre>
@user1 = User.find_by(name: "student2064")
stub_current_user(@user1, @user1.role.name, @user1.role)
visit '/student_task/list'
# Assignment name
expect(page).to have_content('final2')

click_link 'final2'
expect(page).to have_content('Submit or Review work for final2')

click_link 'Signup sheet'
expect(page).to have_content('Signup sheet for final2 assignment')

# click Signup check button
@assignment_id = Assignment.first.id
visit "/sign_up_sheet/sign_up?id=#{@assignment_id}&topic_id=1"
expect(page).to have_content('Your topic(s): Hello world! ')

visit '/student_task/list'
expect(page).to have_content('final2')

click_link 'final2'
expect(page).to have_content('Submit or Review work for final2')

click_link 'Your team'
expect(page).to have_content('final2_Team1')

fill_in 'user_name', with: 'student2065'
click_button 'Invite'
expect(page).to have_content('Waiting for reply')
</pre>

===Test Cases===
====To invite a student with no topic====
<pre>
describe 'one student who signup for a topic should send an invitation to the other student who has no topic' do
before(:each) do
user = User.find_by(name: "student2065")
stub_current_user(user, user.role.name, user.role)
visit '/student_task/list'
expect(page).to have_content('final2')

click_link 'final2'
click_link 'Your team'
end

it 'is able to accept the invitation and form team' do
visit '/invitations/accept?inv_id=1&student_id=1&team_id=0'
visit '/student_teams/view?student_id=1'
expect(page).to have_content('Team Name: final2_Team1')
end

it 'is not able to form team on rejecting' do
visit '/invitations/decline?inv_id=1&student_id=1'
visit '/student_teams/view?student_id=1'
expect(page).to have_content('You no longer have a team!')
end
end
</pre>

====To invite a student with a topic====
<pre>
describe 'one student who has a topic sends an invitation to other student who also has a topic' do
before(:each) do
user = User.find_by(name: "student2065")
stub_current_user(user, user.role.name, user.role)
visit '/student_task/list'
expect(page).to have_content('final2')

click_link 'final2'
expect(page).to have_content('Submit or Review work for final2')

click_link 'Signup sheet'
expect(page).to have_content('Signup sheet for final2 assignment')

visit '/sign_up_sheet/sign_up?assignment_id=1&id=2'
visit '/student_task/list'
click_link 'final2'
click_link 'Your team'
end

it 'Student should accept the invitation sent by the other student and both have topics' do
visit '/invitations/accept?inv_id=1&student_id=1&team_id=2'
visit '/student_teams/view?student_id=1'
expect(page).to have_content('Team Name: final2_Team1')
end

it 'student should reject the invitation sent by the other student and both have topics' do
visit '/invitations/decline?inv_id=1&student_id=1'
visit '/student_teams/view?student_id=1'
expect(page).to have_content('Team Name: final2_Team2')
end
end
</pre>

====To retract an invitation====
<pre>
describe 'one student sends an invitation and retracts it' do
before(:each) do
visit '/student_task/list'
click_link 'final2'
click_link 'Your team'
end
it 'should remove entry from database' do
before_count = Invitation.count
click_link 'Retract'
expect(Invitation.count).to eq(before_count - 1)
end
end
</pre>

===Feature Test Scenarios===
Some of the possible test cases which can be used for the controllers are given below.

* Test for create method in invitations controller: Before sending out an invitation to another student there a lot of checks that need to be performed such as checking if the invitee is a valid user, if the student is a participant in the project etc. All these scenarios are tested and finally, we make sure that a new invitation has been created in the database. The image below gives a visual representation of all the checks performed before sending out an invitation.
[[File:InvitationCTest2.png | center]]

* Test for create method in join teams request controller: Similar to the create method in the invitations controller we need to do a lot of checks before sending out a new join team request. The below flow chart explains all the checks that need to be asserted before sending out a new request.
[[File:Test1.png|center]]

* Test for cancel method: The cancel method is called when the student who sends out an invitation wishes to retract the sent invitation. In this scenario the invitation is destroyed from the database and we assert that change by checking the change in the count of the database. The below diagram is attached for further clarity.
[[File:InvitationsCTest3.png | center ]]

* Test for decline method: In this test, we assert the change of reply_status to 'D' in the database.

Further improvements to this project would be to write feature tests for the scenarios discussed above.

== Running project remotely ==
VCL is used to host the project remotely. The login credentials as an instructor are "instructor6" with password "password". To log in as a student, you can use 'student5425' with password 'password'

http://152.46.20.227:3000

== References ==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/kira0992/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

CSC/ECE 517 Spring 2017/oss E1712

2017-03-31T06:40:08Z

Rmandav: /* Join Team Requests Controller */

== Introduction ==
This project is part of an educational web application called Expertiza. This wiki gives the details on the refactoring tasks undertaken as part of continuous improvement of Expertiza.

===Background===
[[Expertiza_documentation|Expertiza]] is an open source project managed by the faculty and students of NCSU. It is a web application which offers a platform for assignments and allows learning through peer reviews.

===Motivation===
In the existing code the InvitationController and the JoinTeamRequestsController do the expected task but the there is a lot of redundancy and duplicity in the code, and the comments in the code are few and sparse. The aim of our project was to reduce the complexity of the controller by removing redundant code adding comments so that the code is easy to understand and all the variables used in the code are clearly explained.

==Current Implementation==
===Invitations Controller===
Invitations controller handles the functions required to send invitations out to potential teammates for a project. Once a student decides to invite someone into his assignment team the controller performs some checks before sending out the invitations. These checks are performed in the create function. The current implementation has a lot of redundant code and many nested if statements. The ABC size of the method is also very high. The controller also has functions which take care of cases where an invitee accepts/declines an invitation. There is also an option to retract a sent invitation which is handled by the cancel function in the controller.
====Tasks Identified====
* Rename to invitations_controller.rb, in accordance with current naming convention.
* The ABC size for create method is too high and needs to be refactored along by removing other nested if's in create and update_join_team_request methods.
* Use find_by instead of find_by_name and find_by_user_id_and_assignment_id.
* Add comments explaining what each method does, and comments on how important variables are used.
* Pending invitations needs to be displayed in the same format as other tables.
* Feature tests need to be written for the controller

===Join Team Requests Controller===
JoinTeamRequests controller deals with the actions to be performed after a student comes across an advertisement to join a project team. Whenever a project team creates an advertisement for others to join their team, students can see a link to the advertisement in the signup sheet. Once the student clicks on the link to the advertisement the student can then request to join the team. The create function in the JoinTeamRequestsController handles the checks before sending out the request. Again, the ABC size for this method is very high as there a lot of nested if conditions. Also, there is duplicate code in some of the functions in this controller which can be moved to a separate function.
====Tasks Identified====
* Add comments on why some important variables are used.
* The ABC size for create method is too high.
* Nested if's need to be refactored.
* Duplicate code needs to be removed.
* Pending join team requests needs to be displayed in the same format as other tables
* Feature tests need to be written for the controller
* Decline request is not working: Post route is not defined
* JoinTeamRequest.find(params[:id]. This retrieval is common to five methods which are :show, :edit, :update, :destroy, :decline. Can be put into private before action

==Change Specifics==
The tasks identified above were implemented and the details are given below.
===Invitations Controller===
* A new private function check_users was added which performs some basic checks before the create function is called. In the original implementation, there were a lot of nested if conditions which checked if a user is valid, is a participant in the project, and if the team has slots available. All these checks were the cause of the nested if statements because they needed to be checked before an invitation is sent out to a student. The nested if's were removed by moving all these checks into the private function thereby reducing the ABC size of the create method.
* Nested if statements in the update_join_team_request were removed by breaking the nested statements into separate conditions and using return when the condition fails. For example, when checking if the user is valid, instead of using a nested condition to check validity, if the user is not valid then we throw an error message and return from the function.
* Call to the method find_by_user_id_and_assignment_id has been replaced by find_by and passing the user_id and assignment_id as arguments to find_by. The code snippet showing the change made is shown below.
Before refactoring
<pre>AssignmentParticipant.find_by_user_id_and_assignment_id(inviter_user_id, assignment_id)</pre>
After refactoring
<pre>AssignmentParticipant.find_by(user_id: inviter_user_id, parent_id: assignment_id)</pre>
* Styling was added to the pending invitations table in accordance with the existing tables so that the view is uniform across the entire page.
* The name of the controller was changed in accordance with the current naming convention and comments were added explaining why some important variables were used and also giving more clarity to whoever wants to modify the code in the future. There were very few comments earlier and they did not explain much about what was going on in the functions.

===Join Team Requests Controller===
* A new private function check_team was added which takes most of the initial checks that are performed before a new join team request is successfully created. This significantly reduces the ABC size of the create method as almost all the conditional statements are moved to the private function which is called before the create function is called. The nested conditionals are also removed by making use of return statements just as in the invitations controller methods.
* The methods index, show and new all have code which is repeated. Another private function respond_after was written which makes the code DRYer.
* The view here too contained tables which did not follow the styling that is present throughout the other sections of the page. Styling was added to the pending join team requests table to make it same as the other tables.
* This controller had very comments and most of the variables were not explained, especially the codes used for reply_status which is used when a new request is sent and updated is not explained at all. The status codes 'A' - awaiting a reply etc. are clearly commented. Comments were also added explaining important pieces of code.
* POST route added to decline action in the routes file
* Common statement in show, edit, update, destroy, decline
Before refactoring
<pre> @join_team_request = JoinTeamRequest.find(params[:id]) </pre>
After refactoring
added private method find_request
<pre>
def find_request
@join_team_request = JoinTeamRequest.find(params[:id])
end
</pre>
Added before_action to the methods
<pre> before_action :find_request, only: [:show, :edit, :update, :destroy, :decline] </pre>

==Feature Test Scenarios==
Some of the possible test cases which can be used for the controllers are given below.

* Test for create method in invitations controller: Before sending out an invitation to another student there a lot of checks that need to be performed such as checking if the invitee is a valid user, if the student is a participant in the project etc. All these scenarios are tested and finally, we make sure that a new invitation has been created in the database. The image below gives a visual representation of all the checks performed before sending out an invitation.
[[File:InvitationCTest2.png | center]]

* Test for create method in join teams request controller: Similar to the create method in the invitations controller we need to do a lot of checks before sending out a new join team request. The below flow chart explains all the checks that need to be asserted before sending out a new request.
[[File:Test1.png|center]]

* Test for cancel method: The cancel method is called when the student who sends out an invitation wishes to retract the sent invitation. In this scenario the invitation is destroyed from the database and we assert that change by checking the change in the count of the database. The below diagram is attached for further clarity.
[[File:InvitationsCTest3.png | center ]]

* Test for decline method: In this test, we assert the change of reply_status to 'D' in the database.

Further improvements to this project would be to write feature tests for the scenarios discussed above.

== Running project remotely ==
VCL is used to host the project remotely. The login credentials as an instructor are "instructor6" with password "password". To log in as a student, you can use 'student5425' with password 'password'

http://152.46.20.227:3000

== References ==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/kira0992/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

CSC/ECE 517 Spring 2017/oss E1712

2017-03-31T06:36:11Z

Rmandav: /* Tasks Identified */

CSC/ECE 517 Spring 2017/oss E1712

2017-03-31T06:33:33Z

Rmandav: /* Join Team Requests Controller */

CSC/ECE 517 Spring 2017/oss E1712

2017-03-31T06:30:42Z

Rmandav: /* Tasks Identified */

File:Screen Shot 2017-03-26 at 12.20.40 AM.png

2017-03-26T05:15:04Z

Rmandav: uploaded a new version of "File:Screen Shot 2017-03-26 at 12.20.40 AM.png"

create in invitations controller

CSC/ECE 517 Spring 2017/oss E1712

2017-03-26T05:09:15Z

Rmandav: /* Running project remotely */

=== Introduction ===
This project is part of an educational web application called Expertiza. Expertiza is an open source project managed by the faculty and students of NCSU.

Expertiza offers a platform for assignments and allows learning through peer reviews.

=== Description of project: ===
The project involves refactoring of "join_team_requests_controller.rb" and "invitations_controller.rb". The complexity of the methods is reduced and redundant code is removed. Comments are added to make the controllers easier to understand.

Invitations controller handles the functions required to send invitations out to potential teammates for a project.

JoinTeamRequests controller deals with the actions to be performed after a student comes across an advertisement to join a project team.

=== Tasks Identified ===
InvitationController
* Rename to invitations_controller.rb, in accordance with current naming convention.
* The ABC size for create method is too high and needs to be refactored along with removal of other nested if's in some methods
* Use find_by instead of find_by_name and find_by_user_id_and_assignment_id.
* Add comments explaining what each method does, and comments on how important variables are used
JoinTeamRequestsController
* Add comments on why some important variables are used.
* The ABC size for create method is too high and other 'nested-if's are refactored.
* Duplicacy in code is to be removed.

* Fix UI to maintain consistency in displaying information about team members.
Feature tests for theses controllers have to be updated.

=== Running project remotely ===
VCL is used to host the project remotely. The login credentials as an instructor are "instructor6" with password "password".
[152.46.20.227:3000]