Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2019 - Project E1931. Conflict notification

2019-04-19T14:36:28Z

Bbdeshpa: /* Implementation */

This wiki page is for the description of changes made under ECE517 SPRING 2019 PROJECT E1931 CONFLICT NOTIFICATIONS

=Problem Statement=

Current conflict notification sends an email to the instructor whenever two reviews for the same submission differ “significantly” on their scoring (the threshold is specified in the “Notification limit” on the Rubrics tab of assignment creation). Right now an email is sent at any such time one of these conflicts happen, and it links to the review or submission which initiated the notification. It gives the link in raw HTML, but it should give it as a link associated with text, such as the text “this new review” linking to the page that shows the review.

=Existing Feature Description=

Currently, this feature works as follows:

[[File:Flowwork.PNG|center]]

Whenever a new review is submitted, it is compared with the average of the previously submitted reviews. If the difference between the new submission and existing average is more than the threshold limit set, then a mail is sent to the instructor.
With every review submitted for an assignment of a particular student, the average is updated.

==Flaws with the existing Implementation==

===No view exists to analyze the conflict report===
Currently whenever the conflict happens,a summary link is sent to the instructor which contains the score of all the reviews but there is no view where the instructor can see all the conflicts and analyze them.

===Incorrect email message links===
The existing email body uses hardcoded URLs mentioned in models/response.rb file in the method notify_instructor_on_difference. Being hardcoded, these links wouldn't work on other servers where Expertiza is running. For Example, if the setup is done on localhost, the links will not be functional.

[[File:EMAIL.png|center]]

*Conflicting Review which triggered the mail
[[File:Score conflicting.png|center]]

*Summary of all the reviews
[[File:SUMMARY.png|center]]

=What needs to be done=
The scope of this project is to send an email notification to instructor which will contain links to the conflicting review, summary link, and a link to report which can be used for analyzing. The new report will have the information like the Team(having conflicts), the standard deviation for the team review score and pictorial representation of all the review scores. 

The email sent to the instructor should contain the following data on each of the reviews done on this team:
* The name of the team.
* The members (user-IDs and/or names)

One line for each review received. In this line would be
* The name of the person (or team) that submitted the review, which would be hyperlinked to the review itself,
* The score given for the review,
* A bar chart showing pictorial view
* The average score received from reviewers.
* The standard deviation of the score received from reviewers.
* Review scores that are outside some “tolerance” limit would be highlighted, e.g., boldfaced or shown in a different color. Probably the tolerance should be, perhaps, one or two standard deviations from the mean.

=Implementation=

*'''Feature 1:''' New view to show the conflict report
A new view of the report which will have the following information:- 
* The name of the team.
* The members (user-IDs and/or names)
* The name of the person (or team) that submitted the review, which would be hyperlinked to the review itself,
* The score given for the review,
* A bar chart showing pictorial view
* The average score received from reviewers.
* The standard deviation of the score received from reviewers.

This view will have a report of all the teams on one page.
This report link will be added to the mail that is already being sent whenever some conflict happens.
This report will be also accessible from the reports dropdown for the instructor.
*Sample view of the new report (The view will contain all the columns as mentioned above)-
[[File: Capture.PNG|center]]
 
*'''Feature 2:''' No hardcoded URLs
Hardcoded URLs will be managed by the config file in order to make these links functional on every server running Expertiza and raw URLs will be given some meaningful names

=Files to be changed in this Project=
* [https://github.com/expertiza/expertiza/blob/master/app/mailers/mailer.rb mailer.rb]
* [https://github.com/expertiza/expertiza/tree/master/config Config File]
* [https://github.com/expertiza/expertiza/blob/master/app/models/response.rb response.rb]
* [https://github.com/expertiza/expertiza/blob/master/app/controllers/reports_controller.rb Response Controller]
* [https://github.com/expertiza/expertiza/blob/master/app/helpers/report_formatter_helper.rb Report Format Helper]
* [https://github.com/expertiza/expertiza/tree/master/app/views/reports Reports View]
A new option will be added to view the conflict report in the _searchbox.html.erb.A new view will be added for the same.

=Test Plan=

To test code implementation and correctness of the modified feature, we plan to do the following tests:-

*Run and pass existing RSpec Tests
*Develop New RSpec Tests for the new code
*UI testing on the deployed project

==Rspec Testing==
Rspec test files to be updated -
*[https://github.com/expertiza/expertiza/blob/master/spec/controllers/reports_controller_spec.rb Reports Controller Spec]
*[https://github.com/expertiza/expertiza/blob/master/spec/controllers/response_controller_spec.rb Response Controller Spec]
*[https://github.com/expertiza/expertiza/blob/master/spec/models/response_spec.rb Response spec]
*[https://github.com/expertiza/expertiza/blob/master/spec/models/mailer_spec.rb mailer spec]

[Screenshots to be populated after coding is complete]

==UI Testing==
[Screenshots/video to be populated after coding is complete]

=References=
* [https://github.com/expertiza/expertiza expertiza]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification Previous Work]
* [https://github.com/expertiza/expertiza/pull/1329 Previous Pull Request]
* [https://rubygems.org/gems/standard-deviation/versions/0.1.1 Standard-Deviation gem]
* [https://github.com/jtescher/descriptive-statistics descriptive-statistics gem]

=Team=

[mailto:aarya@ncsu.edu Abhishek Arya] 
[mailto:bbdeshpa@ncsu.edu Bhargav Deshpande] 
[mailto:rkaur@ncsu.edu Ramandeep Kaur] 
[mailto:uschatto@ncsu.edu Udita Chattopadhyay]

CSC/ECE 517 Spring 2019 - Project E1931. Conflict notification

2019-04-19T14:33:28Z

Bbdeshpa: /* What needs to be done */

This wiki page is for the description of changes made under ECE517 SPRING 2019 PROJECT E1931 CONFLICT NOTIFICATIONS

=Problem Statement=

Current conflict notification sends an email to the instructor whenever two reviews for the same submission differ “significantly” on their scoring (the threshold is specified in the “Notification limit” on the Rubrics tab of assignment creation). Right now an email is sent at any such time one of these conflicts happen, and it links to the review or submission which initiated the notification. It gives the link in raw HTML, but it should give it as a link associated with text, such as the text “this new review” linking to the page that shows the review.

=Existing Feature Description=

Currently, this feature works as follows:

[[File:Flowwork.PNG|center]]

Whenever a new review is submitted, it is compared with the average of the previously submitted reviews. If the difference between the new submission and existing average is more than the threshold limit set, then a mail is sent to the instructor.
With every review submitted for an assignment of a particular student, the average is updated.

==Flaws with the existing Implementation==

===No view exists to analyze the conflict report===
Currently whenever the conflict happens,a summary link is sent to the instructor which contains the score of all the reviews but there is no view where the instructor can see all the conflicts and analyze them.

===Incorrect email message links===
The existing email body uses hardcoded URLs mentioned in models/response.rb file in the method notify_instructor_on_difference. Being hardcoded, these links wouldn't work on other servers where Expertiza is running. For Example, if the setup is done on localhost, the links will not be functional.

[[File:EMAIL.png|center]]

*Conflicting Review which triggered the mail
[[File:Score conflicting.png|center]]

*Summary of all the reviews
[[File:SUMMARY.png|center]]

=What needs to be done=
The scope of this project is to send an email notification to instructor which will contain links to the conflicting review, summary link, and a link to report which can be used for analyzing. The new report will have the information like the Team(having conflicts), the standard deviation for the team review score and pictorial representation of all the review scores. 

The email sent to the instructor should contain the following data on each of the reviews done on this team:
* The name of the team.
* The members (user-IDs and/or names)

One line for each review received. In this line would be
* The name of the person (or team) that submitted the review, which would be hyperlinked to the review itself,
* The score given for the review,
* A bar chart showing pictorial view
* The average score received from reviewers.
* The standard deviation of the score received from reviewers.
* Review scores that are outside some “tolerance” limit would be highlighted, e.g., boldfaced or shown in a different color. Probably the tolerance should be, perhaps, one or two standard deviations from the mean.

=Implementation=

*'''Feature 1:''' No hardcoded URLs
Hardcoded URLs will be managed by the config file in order to make these links functional on every server running Expertiza and raw URLs will be given some meaningful names

*'''Feature 2:''' New view to show the conflict report
A new view of the report which will have the following information:- 
*Name of the team 
*Standard deviation 
*Graph showing a plot of the review scores vs the team name 

This view will have a report of all the teams on one page.
This report link will be added to the mail that is already being sent whenever some conflict happens.
*Sample view of the new report -
[[File: Capture.PNG|center]]

=Files to be changed in this Project=
* [https://github.com/expertiza/expertiza/blob/master/app/mailers/mailer.rb mailer.rb]
* [https://github.com/expertiza/expertiza/tree/master/config Config File]
* [https://github.com/expertiza/expertiza/blob/master/app/models/response.rb response.rb]
* [https://github.com/expertiza/expertiza/blob/master/app/controllers/reports_controller.rb Response Controller]
* [https://github.com/expertiza/expertiza/blob/master/app/helpers/report_formatter_helper.rb Report Format Helper]
* [https://github.com/expertiza/expertiza/tree/master/app/views/reports Reports View]
A new option will be added to view the conflict report in the _searchbox.html.erb.A new view will be added for the same.

=Test Plan=

To test code implementation and correctness of the modified feature, we plan to do the following tests:-

*Run and pass existing RSpec Tests
*Develop New RSpec Tests for the new code
*UI testing on the deployed project

==Rspec Testing==
Rspec test files to be updated -
*[https://github.com/expertiza/expertiza/blob/master/spec/controllers/reports_controller_spec.rb Reports Controller Spec]
*[https://github.com/expertiza/expertiza/blob/master/spec/controllers/response_controller_spec.rb Response Controller Spec]
*[https://github.com/expertiza/expertiza/blob/master/spec/models/response_spec.rb Response spec]
*[https://github.com/expertiza/expertiza/blob/master/spec/models/mailer_spec.rb mailer spec]

[Screenshots to be populated after coding is complete]

==UI Testing==
[Screenshots/video to be populated after coding is complete]

=References=
* [https://github.com/expertiza/expertiza expertiza]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification Previous Work]
* [https://github.com/expertiza/expertiza/pull/1329 Previous Pull Request]
* [https://rubygems.org/gems/standard-deviation/versions/0.1.1 Standard-Deviation gem]
* [https://github.com/jtescher/descriptive-statistics descriptive-statistics gem]

=Team=

[mailto:aarya@ncsu.edu Abhishek Arya] 
[mailto:bbdeshpa@ncsu.edu Bhargav Deshpande] 
[mailto:rkaur@ncsu.edu Ramandeep Kaur] 
[mailto:uschatto@ncsu.edu Udita Chattopadhyay]

CSC/ECE 517 Spring 2019 - Project E1931. Conflict notification

2019-04-19T14:29:22Z

Bbdeshpa: /* Implementation */

This wiki page is for the description of changes made under ECE517 SPRING 2019 PROJECT E1931 CONFLICT NOTIFICATIONS

=Problem Statement=

Current conflict notification sends an email to the instructor whenever two reviews for the same submission differ “significantly” on their scoring (the threshold is specified in the “Notification limit” on the Rubrics tab of assignment creation). Right now an email is sent at any such time one of these conflicts happen, and it links to the review or submission which initiated the notification. It gives the link in raw HTML, but it should give it as a link associated with text, such as the text “this new review” linking to the page that shows the review.

=Existing Feature Description=

Currently, this feature works as follows:

[[File:Flowwork.PNG|center]]

Whenever a new review is submitted, it is compared with the average of the previously submitted reviews. If the difference between the new submission and existing average is more than the threshold limit set, then a mail is sent to the instructor.
With every review submitted for an assignment of a particular student, the average is updated.

==Flaws with the existing Implementation==

===No view exists to analyze the conflict report===
Currently whenever the conflict happens,a summary link is sent to the instructor which contains the score of all the reviews but there is no view where the instructor can see all the conflicts and analyze them.

===Incorrect email message links===
The existing email body uses hardcoded URLs mentioned in models/response.rb file in the method notify_instructor_on_difference. Being hardcoded, these links wouldn't work on other servers where Expertiza is running. For Example, if the setup is done on localhost, the links will not be functional.

[[File:EMAIL.png|center]]

*Conflicting Review which triggered the mail
[[File:Score conflicting.png|center]]

*Summary of all the reviews
[[File:SUMMARY.png|center]]

=What needs to be done=
The scope of this project is to send an email notification to instructor which will contain links to the conflicting review, summary link, and a link to report which can be used for analyzing. The new report will have the information like the Team(having conflicts), the standard deviation for the team review score and pictorial representation of all the review scores. 

The email sent to the instructor should contain the following data on each of the reviews done on this team:
* The name of the team.
* The members (user-IDs and/or names)
* One line for each review received. In this line would be
* The name of the person (or team) that submitted the review, which would be hyperlinked to the review itself,
* The score given for the review,
* A bar chart showing pictorial view
* The average score received from reviewers.
* The standard deviation of the score received from reviewers.
* Review scores that are outside some “tolerance” limit would be highlighted, e.g., boldfaced or shown in a different color. Probably the tolerance should be, perhaps, one or two standard deviations from the mean.

=Implementation=

*'''Feature 1:''' No hardcoded URLs
Hardcoded URLs will be managed by the config file in order to make these links functional on every server running Expertiza and raw URLs will be given some meaningful names

*'''Feature 2:''' New view to show the conflict report
A new view of the report which will have the following information:- 
*Name of the team 
*Standard deviation 
*Graph showing a plot of the review scores vs the team name 

This view will have a report of all the teams on one page.
This report link will be added to the mail that is already being sent whenever some conflict happens.
*Sample view of the new report -
[[File: Capture.PNG|center]]

=Files to be changed in this Project=
* [https://github.com/expertiza/expertiza/blob/master/app/mailers/mailer.rb mailer.rb]
* [https://github.com/expertiza/expertiza/tree/master/config Config File]
* [https://github.com/expertiza/expertiza/blob/master/app/models/response.rb response.rb]
* [https://github.com/expertiza/expertiza/blob/master/app/controllers/reports_controller.rb Response Controller]
* [https://github.com/expertiza/expertiza/blob/master/app/helpers/report_formatter_helper.rb Report Format Helper]
* [https://github.com/expertiza/expertiza/tree/master/app/views/reports Reports View]
A new option will be added to view the conflict report in the _searchbox.html.erb.A new view will be added for the same.

=Test Plan=

To test code implementation and correctness of the modified feature, we plan to do the following tests:-

*Run and pass existing RSpec Tests
*Develop New RSpec Tests for the new code
*UI testing on the deployed project

==Rspec Testing==
Rspec test files to be updated -
*[https://github.com/expertiza/expertiza/blob/master/spec/controllers/reports_controller_spec.rb Reports Controller Spec]
*[https://github.com/expertiza/expertiza/blob/master/spec/controllers/response_controller_spec.rb Response Controller Spec]
*[https://github.com/expertiza/expertiza/blob/master/spec/models/response_spec.rb Response spec]
*[https://github.com/expertiza/expertiza/blob/master/spec/models/mailer_spec.rb mailer spec]

[Screenshots to be populated after coding is complete]

==UI Testing==
[Screenshots/video to be populated after coding is complete]

=References=
* [https://github.com/expertiza/expertiza expertiza]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification Previous Work]
* [https://github.com/expertiza/expertiza/pull/1329 Previous Pull Request]
* [https://rubygems.org/gems/standard-deviation/versions/0.1.1 Standard-Deviation gem]
* [https://github.com/jtescher/descriptive-statistics descriptive-statistics gem]

=Team=

[mailto:aarya@ncsu.edu Abhishek Arya] 
[mailto:bbdeshpa@ncsu.edu Bhargav Deshpande] 
[mailto:rkaur@ncsu.edu Ramandeep Kaur] 
[mailto:uschatto@ncsu.edu Udita Chattopadhyay]

CSC/ECE 517 Spring 2019 - Project E1931. Conflict notification

2019-04-19T14:27:01Z

Bbdeshpa: /* What needs to be done */

This wiki page is for the description of changes made under ECE517 SPRING 2019 PROJECT E1931 CONFLICT NOTIFICATIONS

=Problem Statement=

Current conflict notification sends an email to the instructor whenever two reviews for the same submission differ “significantly” on their scoring (the threshold is specified in the “Notification limit” on the Rubrics tab of assignment creation). Right now an email is sent at any such time one of these conflicts happen, and it links to the review or submission which initiated the notification. It gives the link in raw HTML, but it should give it as a link associated with text, such as the text “this new review” linking to the page that shows the review.

=Existing Feature Description=

Currently, this feature works as follows:

[[File:Flowwork.PNG|center]]

Whenever a new review is submitted, it is compared with the average of the previously submitted reviews. If the difference between the new submission and existing average is more than the threshold limit set, then a mail is sent to the instructor.
With every review submitted for an assignment of a particular student, the average is updated.

==Flaws with the existing Implementation==

===No view exists to analyze the conflict report===
Currently whenever the conflict happens,a summary link is sent to the instructor which contains the score of all the reviews but there is no view where the instructor can see all the conflicts and analyze them.

===Incorrect email message links===
The existing email body uses hardcoded URLs mentioned in models/response.rb file in the method notify_instructor_on_difference. Being hardcoded, these links wouldn't work on other servers where Expertiza is running. For Example, if the setup is done on localhost, the links will not be functional.

[[File:EMAIL.png|center]]

*Conflicting Review which triggered the mail
[[File:Score conflicting.png|center]]

*Summary of all the reviews
[[File:SUMMARY.png|center]]

=What needs to be done=
The scope of this project is to send an email notification to instructor which will contain links to the conflicting review, summary link, and a link to report which can be used for analyzing. The new report will have the information like the Team(having conflicts), the standard deviation for the team review score and pictorial representation of all the review scores. 

The email sent to the instructor should contain the following data on each of the reviews done on this team:
* The name of the team.
* The members (user-IDs and/or names)
* One line for each review received. In this line would be
* The name of the person (or team) that submitted the review, which would be hyperlinked to the review itself,
* The score given for the review,
* A bar chart showing pictorial view
* The average score received from reviewers.
* The standard deviation of the score received from reviewers.
* Review scores that are outside some “tolerance” limit would be highlighted, e.g., boldfaced or shown in a different color. Probably the tolerance should be, perhaps, one or two standard deviations from the mean.

=Implementation=

*'''Feature 1:''' No hardcoded URLs
Hardcoded URLs will be managed by the config file in order to make these links functional on every server running Expertiza

*'''Feature 2:''' New view to show the conflict report
A new view of the report which will have the following information:- 
*Name of the team 
*Standard deviation 
*Graph showing a plot of the review scores vs the team name 

This view will have a report of all the teams on one page.
This report link will be added to the mail that is already being sent whenever some conflict happens.
*Sample view of the new report -
[[File: Capture.PNG|center]]

=Files to be changed in this Project=
* [https://github.com/expertiza/expertiza/blob/master/app/mailers/mailer.rb mailer.rb]
* [https://github.com/expertiza/expertiza/tree/master/config Config File]
* [https://github.com/expertiza/expertiza/blob/master/app/models/response.rb response.rb]
* [https://github.com/expertiza/expertiza/blob/master/app/controllers/reports_controller.rb Response Controller]
* [https://github.com/expertiza/expertiza/blob/master/app/helpers/report_formatter_helper.rb Report Format Helper]
* [https://github.com/expertiza/expertiza/tree/master/app/views/reports Reports View]
A new option will be added to view the conflict report in the _searchbox.html.erb.A new view will be added for the same.

=Test Plan=

To test code implementation and correctness of the modified feature, we plan to do the following tests:-

*Run and pass existing RSpec Tests
*Develop New RSpec Tests for the new code
*UI testing on the deployed project

==Rspec Testing==
Rspec test files to be updated -
*[https://github.com/expertiza/expertiza/blob/master/spec/controllers/reports_controller_spec.rb Reports Controller Spec]
*[https://github.com/expertiza/expertiza/blob/master/spec/controllers/response_controller_spec.rb Response Controller Spec]
*[https://github.com/expertiza/expertiza/blob/master/spec/models/response_spec.rb Response spec]
*[https://github.com/expertiza/expertiza/blob/master/spec/models/mailer_spec.rb mailer spec]

[Screenshots to be populated after coding is complete]

==UI Testing==
[Screenshots/video to be populated after coding is complete]

=References=
* [https://github.com/expertiza/expertiza expertiza]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification Previous Work]
* [https://github.com/expertiza/expertiza/pull/1329 Previous Pull Request]
* [https://rubygems.org/gems/standard-deviation/versions/0.1.1 Standard-Deviation gem]
* [https://github.com/jtescher/descriptive-statistics descriptive-statistics gem]

=Team=

[mailto:aarya@ncsu.edu Abhishek Arya] 
[mailto:bbdeshpa@ncsu.edu Bhargav Deshpande] 
[mailto:rkaur@ncsu.edu Ramandeep Kaur] 
[mailto:uschatto@ncsu.edu Udita Chattopadhyay]

CSC/ECE 517 Spring 2019 - Project E1931. Conflict notification

2019-04-19T14:22:02Z

Bbdeshpa: /* Problem Statement */

This wiki page is for the description of changes made under ECE517 SPRING 2019 PROJECT E1931 CONFLICT NOTIFICATIONS

=Problem Statement=

Current conflict notification sends an email to the instructor whenever two reviews for the same submission differ “significantly” on their scoring (the threshold is specified in the “Notification limit” on the Rubrics tab of assignment creation). Right now an email is sent at any such time one of these conflicts happen, and it links to the review or submission which initiated the notification. It gives the link in raw HTML, but it should give it as a link associated with text, such as the text “this new review” linking to the page that shows the review.

=Existing Feature Description=

Currently, this feature works as follows:

[[File:Flowwork.PNG|center]]

Whenever a new review is submitted, it is compared with the average of the previously submitted reviews. If the difference between the new submission and existing average is more than the threshold limit set, then a mail is sent to the instructor.
With every review submitted for an assignment of a particular student, the average is updated.

==Flaws with the existing Implementation==

===No view exists to analyze the conflict report===
Currently whenever the conflict happens,a summary link is sent to the instructor which contains the score of all the reviews but there is no view where the instructor can see all the conflicts and analyze them.

===Incorrect email message links===
The existing email body uses hardcoded URLs mentioned in models/response.rb file in the method notify_instructor_on_difference. Being hardcoded, these links wouldn't work on other servers where Expertiza is running. For Example, if the setup is done on localhost, the links will not be functional.

[[File:EMAIL.png|center]]

*Conflicting Review which triggered the mail
[[File:Score conflicting.png|center]]

*Summary of all the reviews
[[File:SUMMARY.png|center]]

=What needs to be done=
The scope of this project is to send an email notification to instructor which will contain links to the conflicting review, summary link, and a link to report which can be used for analyzing. The new report will have the information like the Team(having conflicts), the standard deviation for the team review score and pictorial representation of all the review scores.

=Implementation=

*'''Feature 1:''' No hardcoded URLs
Hardcoded URLs will be managed by the config file in order to make these links functional on every server running Expertiza

*'''Feature 2:''' New view to show the conflict report
A new view of the report which will have the following information:- 
*Name of the team 
*Standard deviation 
*Graph showing a plot of the review scores vs the team name 

This view will have a report of all the teams on one page.
This report link will be added to the mail that is already being sent whenever some conflict happens.
*Sample view of the new report -
[[File: Capture.PNG|center]]

=Files to be changed in this Project=
* [https://github.com/expertiza/expertiza/blob/master/app/mailers/mailer.rb mailer.rb]
* [https://github.com/expertiza/expertiza/tree/master/config Config File]
* [https://github.com/expertiza/expertiza/blob/master/app/models/response.rb response.rb]
* [https://github.com/expertiza/expertiza/blob/master/app/controllers/reports_controller.rb Response Controller]
* [https://github.com/expertiza/expertiza/blob/master/app/helpers/report_formatter_helper.rb Report Format Helper]
* [https://github.com/expertiza/expertiza/tree/master/app/views/reports Reports View]
A new option will be added to view the conflict report in the _searchbox.html.erb.A new view will be added for the same.

=Test Plan=

To test code implementation and correctness of the modified feature, we plan to do the following tests:-

*Run and pass existing RSpec Tests
*Develop New RSpec Tests for the new code
*UI testing on the deployed project

==Rspec Testing==
Rspec test files to be updated -
*[https://github.com/expertiza/expertiza/blob/master/spec/controllers/reports_controller_spec.rb Reports Controller Spec]
*[https://github.com/expertiza/expertiza/blob/master/spec/controllers/response_controller_spec.rb Response Controller Spec]
*[https://github.com/expertiza/expertiza/blob/master/spec/models/response_spec.rb Response spec]
*[https://github.com/expertiza/expertiza/blob/master/spec/models/mailer_spec.rb mailer spec]

[Screenshots to be populated after coding is complete]

==UI Testing==
[Screenshots/video to be populated after coding is complete]

=References=
* [https://github.com/expertiza/expertiza expertiza]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification Previous Work]
* [https://github.com/expertiza/expertiza/pull/1329 Previous Pull Request]
* [https://rubygems.org/gems/standard-deviation/versions/0.1.1 Standard-Deviation gem]
* [https://github.com/jtescher/descriptive-statistics descriptive-statistics gem]

=Team=

[mailto:aarya@ncsu.edu Abhishek Arya] 
[mailto:bbdeshpa@ncsu.edu Bhargav Deshpande] 
[mailto:rkaur@ncsu.edu Ramandeep Kaur] 
[mailto:uschatto@ncsu.edu Udita Chattopadhyay]

E1914 Refactor users controller

2019-03-25T16:41:54Z

Bbdeshpa: /* Design choices */

This is an Expertiza based OSS Project.

== Problems with the current implementation==
1) The users_controller.rb file included the standard CRUD methods for a User model along with methods for other workflows. The users_controller.rb file handled the creation and management of a RequestedUser object. 
2) The users_controller included a few methods which have a bad name or lack documentation. 
3) The forms that come after "Request Account" button is clicked need to be changed. 
4) When a list of all users are shown, the list is not paginated.

== Solutions to the problems ==
=== Separate all methods related to the workflow of a RequestedUser object ===
Earlier, there was no controllers for a RequestedUser object and these were handled by the Users controller itself. We separated the RequestedUser workflow from the Users and we renamed the RequestedUser model to AccountRequest.
As a part of this refractoring activity, we created a new controller was created called the account_requests_controller to handle the workflow of an AccountRequest
The following methods were moved from users_controller to account_requests_controller. 

Following methods were moved from the users_controller to account_requests_controller which was a part of the requirements.
1) created_approved_user 
2) list_pending_requested 
3) request_new 
4) created_requested_user_record 
5) roles_for_request_sign_up 
6) requested_user_params 

=== Rspec testing for AccountRequest ===
We have performed the Rspec testing of our new AccountRequest object. The test results can be seen below:

=== Rspec testing for paginate feature for Users ===
We have performed the Rspec testing of paginate feature for Users object, . These are the test results:

=== Writing comments to make methods more understandable ===
====Wrote comments for the 'foreign' method. The comments include:====
'''1) What the method does:''' This method is used to find the list of roles the current user can embody. 
'''2) Where the method is used:''' Used to display a drop-down selection of roles for the current user in the views. 

====Wrote comments for the show and show_selection methods:====
'''1) What the method does:''' 
''show():'' If the current user is a student, they should only be able to see information about themselves. All other people should be able to see information about themselves or other students. If the request to show() passes these checks, then they are shown the view 'show'. Otherwise, they are redirected to the home page. 
''show_selection():'' If the role of a user's parent is less than the current user or if the current user is requesting to see itself or if user's parent_id does not exist then the show() method is called. All these conditions boil down to whether the current user of the system is authorized to see/edit the information about the user specified in the params. If the requested user does not exist or if the current user is not authorized to see the requested user, then the current user is redirected back to the list page. 
'''2) Scenarios in which show_selection is called:''' in users/list.html.erb, a list of users is shown. On top of the list there is a functionality to search the list. When a person searches for a particular student, and selects that student, the show_selection method is called. If the person is allowed to see that student, the user is directed to the show() method. Otherwise the person stays on the list view. 
'''3) Scenarios in which show() is called:''' From the edit.html.erb, if the person wants to see the information instead of editing it. From show_selection() as described above. 

=== Renaming methods to reflect their actual behavior ===
The get_role method was named more like it would be in Java. It was renamed to 'role' because that is how it would be named in ruby.
We chose to keep the method in the controller instead of moving it to the model because it does not alter the data structure and it also has selection logic.

=== Make GUI changes in the form displayed after "Request Account" button is clicked ===
Only instructor accounts can be created, so the drop-down was removed. 
All form labels were bold-faced. 
The “Self Introduction” label was re-named to “Self-Introduction”. 
The text-box for the self-introduction field now includes a hint "Please include a website name". 
'''Before it looked like:''' 
[[File:Rsz_instructor_dropdown.png]] 

'''After it looks like:''' 
[[File:Rsz_new_instructor.png]] 

=== Paginating the list of users ===
The existing project does not have the feature of pagination for the user list. So, currently, all the users are shown to the instructor. 
The paginate_list method is supposed to paginate the list of users. The method was not called anywhere and also the method logic was incorrect. 
With the latest implementation, the pagination is added with dropdown option - "25", "50", "100" and "ALL" 
The method "paginate_list" is corrected and called at right place 
The default option is kept to "25" to reduce the web page loading time. 
'''Before it looked like:''' 
[[File:Rsz_no_pagination.png]]
 
'''After it looks like:''' 
[[File:Rsz_pagination_implemented.png]]

=== Design choices ===
1. There are some common partials which are used in Users views and Account_requests views. Users and Account_requests are two different entities. So, the team along with our mentor has decided to keep the common partials in both folders so that project remains flexible with future incoming changes regarding these views. Redundant partials are email, name, institution, password, and prefs.

2. We refactored the variables names in requested_users to account_requests (in views, controller actions, etc.) since requested_users is a bad naming choice for our variable. Since we are referring to AccountRequest model in our controllers, such renaming makes sense here. 
For example:
account_request = AccountRequest.all
makes more sense than
requested_users = AccountRequest.all

E1914 Refactor users controller

2019-03-25T02:49:30Z

Bbdeshpa: /* Paginating the list of users */

This is an Expertiza based OSS Project.

== Problems ==
1) The users_controller.rb file included the standard CRUD methods for a User model along with methods for other workflows. The users_controller.rb file handled the creation and management of a RequestedUser object. 
2) The users_controller included a few methods which have a bad name or lack documentation. 
3) The forms that come after "Request Account" button is clicked need to be changed. 
4) When a list of all users are shown, the list is not paginated.

== Solutions to the problems ==
=== Separate all methods related to the workflow of a RequestedUser object ===
The RequestedUser model was renamed to AccountRequest.
A new controller was created called the account_requests_controller.
The following methods were moved from users_controller to account_requests_controller. 
1) created_approved_user 
2) list_pending_requested 
3) request_new 
4) created_requested_user_record 
5) roles_for_request_sign_up 
6) requested_user_params 

=== Writing comments to make methods more understandable ===
====Wrote comments for the 'foreign' method. The comments include:====
'''1) What the method does:''' This method is used to find the list of roles the current user can embody. 
'''2) Where the method is used:''' Used to display a drop-down selection of roles for the current user in the views. 

====Wrote comments for the show and show_selection methods:====
'''1) What the method does:''' 
''show():'' If the current user is a student, they should only be able to see information about themselves. All other people should be able to see information about themselves or other students. If the request to show() passes these checks, then they are shown the view 'show'. Otherwise, they are redirected to the home page. 
''show_selection():'' If the role of a user's parent is less than the current user or if the current user is requesting to see itself or if user's parent_id does not exist then the show() method is called. All these conditions boil down to whether the current user of the system is authorized to see/edit the information about the user specified in the params. If the requested user does not exist or if the current user is not authorized to see the requested user, then the current user is redirected back to the list page. 
'''2) Scenarios in which show_selection is called:''' in users/list.html.erb, a list of users is shown. On top of the list there is a functionality to search the list. When a person searches for a particular student, and selects that student, the show_selection method is called. If the person is allowed to see that student, the user is directed to the show() method. Otherwise the person stays on the list view. 
'''3) Scenarios in which show() is called:''' From the edit.html.erb, if the person wants to see the information instead of editing it. From show_selection() as described above. 

=== Renaming methods to reflect their actual behavior ===
The get_role method was named more like it would be in Java. It was renamed to 'role' because that is how it would be named in ruby.
We chose to keep the method in the controller instead of moving it to the model because it does not alter the data structure and it also has selection logic.

=== Make GUI changes in the form displayed after "Request Account" button is clicked ===
Only instructor accounts can be created, so the drop-down was removed. 
All form labels were bold-faced. 
The “Self Introduction” label was re-named to “Self-Introduction”. 
The text-box for the self-introduction field now includes a hint "Please include a website name". 
'''Before it looked like:''' 
[[File:Rsz_instructor_dropdown.png]] 

'''After it looks like:''' 
[[File:Rsz_new_instructor.png]] 

=== Paginating the list of users ===
The existing project does not have the feature of pagination for the user list. So, currently, all the users are shown to the instructor. 
The paginate_list method is supposed to paginate the list of users. The method was not called anywhere and also the method logic was incorrect. 
With the latest implementation, the pagination is added with dropdown option - "25", "50", "100" and "ALL" 
The method "paginate_list" is corrected and called at right place 
The default option is kept to "25" to reduce the web page loading time. 
'''Before it looked like:''' 
[[File:Rsz_no_pagination.png]]
 
'''After it looks like:''' 
[[File:Rsz_pagination_implemented.png]]

E1914 Refactor users controller

2019-03-25T02:47:41Z

Bbdeshpa: /* Paginating the list of users */

This is an Expertiza based OSS Project.

== Problems ==
1) The users_controller.rb file included the standard CRUD methods for a User model along with methods for other workflows. The users_controller.rb file handled the creation and management of a RequestedUser object. 
2) The users_controller included a few methods which have a bad name or lack documentation. 
3) The forms that come after "Request Account" button is clicked need to be changed. 
4) When a list of all users are shown, the list is not paginated.

== Solutions to the problems ==
=== Separate all methods related to the workflow of a RequestedUser object ===
The RequestedUser model was renamed to AccountRequest.
A new controller was created called the account_requests_controller.
The following methods were moved from users_controller to account_requests_controller. 
1) created_approved_user 
2) list_pending_requested 
3) request_new 
4) created_requested_user_record 
5) roles_for_request_sign_up 
6) requested_user_params 

=== Writing comments to make methods more understandable ===
====Wrote comments for the 'foreign' method. The comments include:====
'''1) What the method does:''' This method is used to find the list of roles the current user can embody. 
'''2) Where the method is used:''' Used to display a drop-down selection of roles for the current user in the views. 

====Wrote comments for the show and show_selection methods:====
'''1) What the method does:''' 
''show():'' If the current user is a student, they should only be able to see information about themselves. All other people should be able to see information about themselves or other students. If the request to show() passes these checks, then they are shown the view 'show'. Otherwise, they are redirected to the home page. 
''show_selection():'' If the role of a user's parent is less than the current user or if the current user is requesting to see itself or if user's parent_id does not exist then the show() method is called. All these conditions boil down to whether the current user of the system is authorized to see/edit the information about the user specified in the params. If the requested user does not exist or if the current user is not authorized to see the requested user, then the current user is redirected back to the list page. 
'''2) Scenarios in which show_selection is called:''' in users/list.html.erb, a list of users is shown. On top of the list there is a functionality to search the list. When a person searches for a particular student, and selects that student, the show_selection method is called. If the person is allowed to see that student, the user is directed to the show() method. Otherwise the person stays on the list view. 
'''3) Scenarios in which show() is called:''' From the edit.html.erb, if the person wants to see the information instead of editing it. From show_selection() as described above. 

=== Renaming methods to reflect their actual behavior ===
The get_role method was named more like it would be in Java. It was renamed to 'role' because that is how it would be named in ruby.
We chose to keep the method in the controller instead of moving it to the model because it does not alter the data structure and it also has selection logic.

=== Make GUI changes in the form displayed after "Request Account" button is clicked ===
Only instructor accounts can be created, so the drop-down was removed. 
All form labels were bold-faced. 
The “Self Introduction” label was re-named to “Self-Introduction”. 
The text-box for the self-introduction field now includes a hint "Please include a website name". 
'''Before it looked like:''' 
[[File:Rsz_instructor_dropdown.png]] 

'''After it looks like:''' 
[[File:Rsz_new_instructor.png]] 

=== Paginating the list of users ===
The existing project does not have the feature of pagination for the user list. So, currently, all the users are shown to the instructor. 
The paginate_list method is supposed to paginate the list of users. The method was not called anywhere and also the method logic was incorrect. 
With the latest implementation, the pagination is added with dropdown option - "25", "50", "100" and "ALL" 
The method "Paginate_list" is corrected and called at right place 
The default option is kept to "25" to reduce the web page loading time. 
'''Before it looked like:''' 
[[File:Rsz_no_pagination.png]]
 
'''After it looks like:''' 
[[File:Rsz_pagination_implemented.png]]

E1914 Refactor users controller

2019-03-25T02:47:19Z

Bbdeshpa: /* Paginating the list of users */

This is an Expertiza based OSS Project.

== Problems ==
1) The users_controller.rb file included the standard CRUD methods for a User model along with methods for other workflows. The users_controller.rb file handled the creation and management of a RequestedUser object. 
2) The users_controller included a few methods which have a bad name or lack documentation. 
3) The forms that come after "Request Account" button is clicked need to be changed. 
4) When a list of all users are shown, the list is not paginated.

== Solutions to the problems ==
=== Separate all methods related to the workflow of a RequestedUser object ===
The RequestedUser model was renamed to AccountRequest.
A new controller was created called the account_requests_controller.
The following methods were moved from users_controller to account_requests_controller. 
1) created_approved_user 
2) list_pending_requested 
3) request_new 
4) created_requested_user_record 
5) roles_for_request_sign_up 
6) requested_user_params 

=== Writing comments to make methods more understandable ===
====Wrote comments for the 'foreign' method. The comments include:====
'''1) What the method does:''' This method is used to find the list of roles the current user can embody. 
'''2) Where the method is used:''' Used to display a drop-down selection of roles for the current user in the views. 

====Wrote comments for the show and show_selection methods:====
'''1) What the method does:''' 
''show():'' If the current user is a student, they should only be able to see information about themselves. All other people should be able to see information about themselves or other students. If the request to show() passes these checks, then they are shown the view 'show'. Otherwise, they are redirected to the home page. 
''show_selection():'' If the role of a user's parent is less than the current user or if the current user is requesting to see itself or if user's parent_id does not exist then the show() method is called. All these conditions boil down to whether the current user of the system is authorized to see/edit the information about the user specified in the params. If the requested user does not exist or if the current user is not authorized to see the requested user, then the current user is redirected back to the list page. 
'''2) Scenarios in which show_selection is called:''' in users/list.html.erb, a list of users is shown. On top of the list there is a functionality to search the list. When a person searches for a particular student, and selects that student, the show_selection method is called. If the person is allowed to see that student, the user is directed to the show() method. Otherwise the person stays on the list view. 
'''3) Scenarios in which show() is called:''' From the edit.html.erb, if the person wants to see the information instead of editing it. From show_selection() as described above. 

=== Renaming methods to reflect their actual behavior ===
The get_role method was named more like it would be in Java. It was renamed to 'role' because that is how it would be named in ruby.
We chose to keep the method in the controller instead of moving it to the model because it does not alter the data structure and it also has selection logic.

=== Make GUI changes in the form displayed after "Request Account" button is clicked ===
Only instructor accounts can be created, so the drop-down was removed. 
All form labels were bold-faced. 
The “Self Introduction” label was re-named to “Self-Introduction”. 
The text-box for the self-introduction field now includes a hint "Please include a website name". 
'''Before it looked like:''' 
[[File:Rsz_instructor_dropdown.png]] 

'''After it looks like:''' 
[[File:Rsz_new_instructor.png]] 

=== Paginating the list of users ===
The existing project does not have the feature of pagination for the user list. So, currently, all the users are shown to the instructor. 
The paginate_list method is supposed to paginate the list of users. The method was not called anywhere and also the method logic was incorrect. 
With the latest implementation, the pagination is added with dropdown option - "25", "50", "100" and "ALL" 
The method "Paginate_list" is corrected and called at right place 
The default option is kept to "25" to reduce the web page loading time. 
'''Before it looked like:''' 
[[File:Rsz_no_pagination.png]]
 
'''After it looks like:''' 
[[File:Rsz_pagination_implemented.png]]

E1914 Refactor users controller

2019-03-25T02:46:56Z

Bbdeshpa: /* Paginating the list of users */

This is an Expertiza based OSS Project.

== Problems ==
1) The users_controller.rb file included the standard CRUD methods for a User model along with methods for other workflows. The users_controller.rb file handled the creation and management of a RequestedUser object. 
2) The users_controller included a few methods which have a bad name or lack documentation. 
3) The forms that come after "Request Account" button is clicked need to be changed. 
4) When a list of all users are shown, the list is not paginated.

== Solutions to the problems ==
=== Separate all methods related to the workflow of a RequestedUser object ===
The RequestedUser model was renamed to AccountRequest.
A new controller was created called the account_requests_controller.
The following methods were moved from users_controller to account_requests_controller. 
1) created_approved_user 
2) list_pending_requested 
3) request_new 
4) created_requested_user_record 
5) roles_for_request_sign_up 
6) requested_user_params 

=== Writing comments to make methods more understandable ===
====Wrote comments for the 'foreign' method. The comments include:====
'''1) What the method does:''' This method is used to find the list of roles the current user can embody. 
'''2) Where the method is used:''' Used to display a drop-down selection of roles for the current user in the views. 

====Wrote comments for the show and show_selection methods:====
'''1) What the method does:''' 
''show():'' If the current user is a student, they should only be able to see information about themselves. All other people should be able to see information about themselves or other students. If the request to show() passes these checks, then they are shown the view 'show'. Otherwise, they are redirected to the home page. 
''show_selection():'' If the role of a user's parent is less than the current user or if the current user is requesting to see itself or if user's parent_id does not exist then the show() method is called. All these conditions boil down to whether the current user of the system is authorized to see/edit the information about the user specified in the params. If the requested user does not exist or if the current user is not authorized to see the requested user, then the current user is redirected back to the list page. 
'''2) Scenarios in which show_selection is called:''' in users/list.html.erb, a list of users is shown. On top of the list there is a functionality to search the list. When a person searches for a particular student, and selects that student, the show_selection method is called. If the person is allowed to see that student, the user is directed to the show() method. Otherwise the person stays on the list view. 
'''3) Scenarios in which show() is called:''' From the edit.html.erb, if the person wants to see the information instead of editing it. From show_selection() as described above. 

=== Renaming methods to reflect their actual behavior ===
The get_role method was named more like it would be in Java. It was renamed to 'role' because that is how it would be named in ruby.
We chose to keep the method in the controller instead of moving it to the model because it does not alter the data structure and it also has selection logic.

=== Make GUI changes in the form displayed after "Request Account" button is clicked ===
Only instructor accounts can be created, so the drop-down was removed. 
All form labels were bold-faced. 
The “Self Introduction” label was re-named to “Self-Introduction”. 
The text-box for the self-introduction field now includes a hint "Please include a website name". 
'''Before it looked like:''' 
[[File:Rsz_instructor_dropdown.png]] 

'''After it looks like:''' 
[[File:Rsz_new_instructor.png]] 

=== Paginating the list of users ===
The existing project does not have the feature of pagination for the user list. So, currently, all the users are shown to the instructor. 
The paginate_list method is supposed to paginate the list of users. The method was not called anywhere and also the method logic was incorrect. 
With the latest implementation, the pagination is added with dropdown option - "25", "50", "100" and "ALL" 
The method "Paginate_list" is corrected and called at right place 
The default option is kept to "25" to reduce the web page loading time. 
'''Before it looked like:''' 
[[File:Rsz_no_pagination.png]]
 
'''After it looks like:''' 
[[File:Rsz_pagination_implemented.png]]

E1914 Refactor users controller

2019-03-25T02:46:30Z

Bbdeshpa: /* Paginating the list of users */

This is an Expertiza based OSS Project.

== Problems ==
1) The users_controller.rb file included the standard CRUD methods for a User model along with methods for other workflows. The users_controller.rb file handled the creation and management of a RequestedUser object. 
2) The users_controller included a few methods which have a bad name or lack documentation. 
3) The forms that come after "Request Account" button is clicked need to be changed. 
4) When a list of all users are shown, the list is not paginated.

== Solutions to the problems ==
=== Separate all methods related to the workflow of a RequestedUser object ===
The RequestedUser model was renamed to AccountRequest.
A new controller was created called the account_requests_controller.
The following methods were moved from users_controller to account_requests_controller. 
1) created_approved_user 
2) list_pending_requested 
3) request_new 
4) created_requested_user_record 
5) roles_for_request_sign_up 
6) requested_user_params 

=== Writing comments to make methods more understandable ===
====Wrote comments for the 'foreign' method. The comments include:====
'''1) What the method does:''' This method is used to find the list of roles the current user can embody. 
'''2) Where the method is used:''' Used to display a drop-down selection of roles for the current user in the views. 

====Wrote comments for the show and show_selection methods:====
'''1) What the method does:''' 
''show():'' If the current user is a student, they should only be able to see information about themselves. All other people should be able to see information about themselves or other students. If the request to show() passes these checks, then they are shown the view 'show'. Otherwise, they are redirected to the home page. 
''show_selection():'' If the role of a user's parent is less than the current user or if the current user is requesting to see itself or if user's parent_id does not exist then the show() method is called. All these conditions boil down to whether the current user of the system is authorized to see/edit the information about the user specified in the params. If the requested user does not exist or if the current user is not authorized to see the requested user, then the current user is redirected back to the list page. 
'''2) Scenarios in which show_selection is called:''' in users/list.html.erb, a list of users is shown. On top of the list there is a functionality to search the list. When a person searches for a particular student, and selects that student, the show_selection method is called. If the person is allowed to see that student, the user is directed to the show() method. Otherwise the person stays on the list view. 
'''3) Scenarios in which show() is called:''' From the edit.html.erb, if the person wants to see the information instead of editing it. From show_selection() as described above. 

=== Renaming methods to reflect their actual behavior ===
The get_role method was named more like it would be in Java. It was renamed to 'role' because that is how it would be named in ruby.
We chose to keep the method in the controller instead of moving it to the model because it does not alter the data structure and it also has selection logic.

=== Make GUI changes in the form displayed after "Request Account" button is clicked ===
Only instructor accounts can be created, so the drop-down was removed. 
All form labels were bold-faced. 
The “Self Introduction” label was re-named to “Self-Introduction”. 
The text-box for the self-introduction field now includes a hint "Please include a website name". 
'''Before it looked like:''' 
[[File:Rsz_instructor_dropdown.png]] 

'''After it looks like:''' 
[[File:Rsz_new_instructor.png]] 

=== Paginating the list of users ===
The existing project does not have the feature of pagination for the user list. So, currently, all the users are shown to the instructor. 
The paginate_list method is supposed to paginate the list of users. The method was not called anywhere and also the method logic was incorrect. 
With the latest implementation, the pagination is added with dropdown option - "25", "50", "100" and "ALL" 
The method "Paginate_list" is corrected and called at right place 
The default option is kept to "25" to reduce the web page loading time. 
'''Before it looked like:''' 
[[File:Rsz_no_pagination.png]]

'''After it looks like:''' 
[[File:Rsz_pagination_implemented.png]]

E1914 Refactor users controller

2019-03-25T02:29:26Z

Bbdeshpa: /* Paginating the list of users */

This is an Expertiza based OSS Project.

== Problems ==
1) The users_controller.rb file included the standard CRUD methods for a User model along with methods for other workflows. The users_controller.rb file handled the creation and management of a RequestedUser object. 
2) The users_controller included a few methods which have a bad name or lack documentation. 
3) The forms that come after "Request Account" button is clicked need to be changed. 
4) When a list of all users are shown, the list is not paginated.

== Solutions to the problems ==
=== Separate all methods related to the workflow of a RequestedUser object ===
The RequestedUser model was renamed to AccountRequest.
A new controller was created called the account_requests_controller.
The following methods were moved from users_controller to account_requests_controller. 
1) created_approved_user 
2) list_pending_requested 
3) request_new 
4) created_requested_user_record 
5) roles_for_request_sign_up 
6) requested_user_params 

=== Writing comments to make methods more understandable ===
====Wrote comments for the 'foreign' method. The comments include:====
'''1) What the method does:''' This method is used to find the list of roles the current user can embody. 
'''2) Where the method is used:''' Used to display a drop-down selection of roles for the current user in the views. 

====Wrote comments for the show and show_selection methods:====
'''1) What the method does:''' 
''show():'' If the current user is a student, they should only be able to see information about themselves. All other people should be able to see information about themselves or other students. If the request to show() passes these checks, then they are shown the view 'show'. Otherwise, they are redirected to the home page. 
''show_selection():'' If the role of a user's parent is less than the current user or if the current user is requesting to see itself or if user's parent_id does not exist then the show() method is called. All these conditions boil down to whether the current user of the system is authorized to see/edit the information about the user specified in the params. If the requested user does not exist or if the current user is not authorized to see the requested user, then the current user is redirected back to the list page. 
'''2) Scenarios in which show_selection is called:''' in users/list.html.erb, a list of users is shown. On top of the list there is a functionality to search the list. When a person searches for a particular student, and selects that student, the show_selection method is called. If the person is allowed to see that student, the user is directed to the show() method. Otherwise the person stays on the list view. 
'''3) Scenarios in which show() is called:''' From the edit.html.erb, if the person wants to see the information instead of editing it. From show_selection() as described above. 

=== Renaming methods to reflect their actual behavior ===
The get_role method was named more like it would be in Java. It was renamed to 'role' because that is how it would be named in ruby.
We chose to keep the method in the controller instead of moving it to the model because it does not alter the data structure and it also has selection logic.

=== Make GUI changes in the form displayed after "Request Account" button is clicked ===
Only instructor accounts can be created, so the drop-down was removed. 
All form labels were bold-faced. 
The “Self Introduction” label was re-named to “Self-Introduction”. 
The text-box for the self-introduction field now includes a hint "Please include a website name". 
'''Before it looked like:''' 
[[File:Rsz_instructor_dropdown.png]] 

'''After it looks like:''' 
[[File:Rsz_new_instructor.png]] 

=== Paginating the list of users ===
The existing project does not have the feature of pagination for the user list. So, currently, all the users are shown to the instructor
The paginate_list method is supposed to paginate the list of users. However, the list of users was not paginated. The method was implemented and called from the correct page.
'''Before it looked like:''' 
[[File:Rsz_no_pagination.png]]

'''After it looks like:''' 
[[File:Rsz_pagination_implemented.png]]