Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T18:26:51Z

Sagupta: /* Approach */

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by displaying alert messages to the authors and the reviewers who will use the newly created Google document links embedded into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza or any google account for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png|thumb=Doceditor.png|center|alt=none|The expected display on the google documents]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png|thumb=Googledoc.png|center|alt=none|The list of hyperlinks a project author would ideally have]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues the reviewer needs log out of the google accounts.
*The authors of the project by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png|thumb=can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without login into other google accounts.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T18:23:08Z

Sagupta: /* Project Description */ Edited Project Description

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by displaying alert messages to the authors and the reviewers who will use the newly created Google document links embedded into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza or any google account for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash dialog box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png|thumb=Doceditor.png|center|alt=none|The expected display on the google documents]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png|thumb=Googledoc.png|center|alt=none|The list of hyperlinks a project author would ideally have]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues the reviewer needs log out of the google accounts.
*The authors of the project by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png|thumb=can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without login into other google accounts.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T18:15:13Z

Sagupta: /* Creating Google document, Setting Up its Link */

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash dialog box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png|thumb=Doceditor.png|center|alt=none|The expected display on the google documents]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png|thumb=Googledoc.png|center|alt=none|The list of hyperlinks a project author would ideally have]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues the reviewer needs log out of the google accounts.
*The authors of the project by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png|thumb=can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without login into other google accounts.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T18:12:03Z

Sagupta: /* Security Risks */

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash dialog box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues the reviewer needs log out of the google accounts.
*The authors of the project by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png|thumb=can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without login into other google accounts.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T18:08:56Z

Sagupta: /* Security Risks */

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash dialog box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues the reviewer needs log out of the google accounts.
*The authors of the project by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without login into other google accounts.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T18:07:44Z

Sagupta: /* Security Risks */

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash dialog box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues the reviewer needs log out of the google accounts.
*The authors of the project by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png|thumb|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without login into other google accounts.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T18:07:05Z

Sagupta: /* Security Risks */

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash dialog box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues the reviewer needs log out of the google accounts.
*The authors of the project by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without login into other google accounts.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T18:04:42Z

Sagupta: /* Security Risks */

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash dialog box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues the reviewer needs log out of the google accounts.
*The authors of the project by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png|center|alt=Alt|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without login into other google accounts.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T18:01:57Z

Sagupta: /* Security Risks */

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash dialog box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues the reviewer needs log out of the google accounts.
*The authors of the project by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png|center|"ScreenShot of google document settings"]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without login into other google accounts.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T18:01:31Z

Sagupta: /* Security Risks */

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash dialog box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues the reviewer needs log out of the google accounts.
*The authors of the project by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png|center|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without login into other google accounts.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T18:00:21Z

Sagupta: /* Security Risks */

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash dialog box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues the reviewer needs log out of the google accounts.
*The authors of the project by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png|center]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without login into other google accounts.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T17:55:15Z

Sagupta: /* Security Risks */ edited all security content

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash dialog box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues the reviewer needs log out of the google accounts.
*The authors of the project by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without login into other google accounts.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T17:42:07Z

Sagupta: /* Key Points To Consider */

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash dialog box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situtation where more than one people comment on the doc and mess up the content.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues we'll be modifying the access rights of the google doc associated with that project.
*We'll by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T17:41:37Z

Sagupta: /* Key Points To Consider */ edited the points to consider

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

The alert message should only pop up when the faculty as indicated to do so
The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash dialog box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situtation where more than one people comment on the doc and mess up the content.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues we'll be modifying the access rights of the google doc associated with that project.
*We'll by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T06:30:06Z

Sagupta: /* Approach */

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

The Google doc editor needs to be embedded in expertiza or it should be made as a pop up window
* The settings for the Google doc should be set to "anyone with link can comment"
* A peer reviewer need not login to Google to comment on the doc, and all peer reviewer comments must be anonymous
* If more than one user comment on the Google doc at the same time, any conflicts that may arise should be handled well

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash dialog box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situtation where more than one people comment on the doc and mess up the content.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues we'll be modifying the access rights of the google doc associated with that project.
*We'll by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T06:29:12Z

Sagupta: /* Approach */ added the approach and modified the database developements

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

The Google doc editor needs to be embedded in expertiza or it should be made as a pop up window
* The settings for the Google doc should be set to "anyone with link can comment"
* A peer reviewer need not login to Google to comment on the doc, and all peer reviewer comments must be anonymous
* If more than one user comment on the Google doc at the same time, any conflicts that may arise should be handled well

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.
The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash dialog box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situtation where more than one people comment on the doc and mess up the content.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues we'll be modifying the access rights of the google doc associated with that project.
*We'll by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T05:40:41Z

Sagupta: /* Project File and Database additions */

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

The Google doc editor needs to be embedded in expertiza or it should be made as a pop up window
* The settings for the Google doc should be set to "anyone with link can comment"
* A peer reviewer need not login to Google to comment on the doc, and all peer reviewer comments must be anonymous
* If more than one user comment on the Google doc at the same time, any conflicts that may arise should be handled well

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situtation where more than one people comment on the doc and mess up the content.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues we'll be modifying the access rights of the google doc associated with that project.
*We'll by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T04:16:37Z

Sagupta: /* Project File and Database additions */

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

The Google doc editor needs to be embedded in expertiza or it should be made as a pop up window
* The settings for the Google doc should be set to "anyone with link can comment"
* A peer reviewer need not login to Google to comment on the doc, and all peer reviewer comments must be anonymous
* If more than one user comment on the Google doc at the same time, any conflicts that may arise should be handled well

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situtation where more than one people comment on the doc and mess up the content.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues we'll be modifying the access rights of the google doc associated with that project.
*We'll by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T04:04:34Z

Sagupta: /* Project File and Database additions */

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

The Google doc editor needs to be embedded in expertiza or it should be made as a pop up window
* The settings for the Google doc should be set to "anyone with link can comment"
* A peer reviewer need not login to Google to comment on the doc, and all peer reviewer comments must be anonymous
* If more than one user comment on the Google doc at the same time, any conflicts that may arise should be handled well

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situtation where more than one people comment on the doc and mess up the content.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues we'll be modifying the access rights of the google doc associated with that project.
*We'll by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table "assignments" and we have made a change to the schema of the table by adding a column "allow_anonymous_commenting" of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: _add_allow_anonymous_commenting_to_assignemnnts.rb
* The factories file in the spec has a variable added with the default value set as 'FALSE'
* _genral.html.erb page in the edit assignments view has a 'check box' and a label added to it.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T03:58:46Z

Sagupta: /* Project File and Database additions */

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

The Google doc editor needs to be embedded in expertiza or it should be made as a pop up window
* The settings for the Google doc should be set to "anyone with link can comment"
* A peer reviewer need not login to Google to comment on the doc, and all peer reviewer comments must be anonymous
* If more than one user comment on the Google doc at the same time, any conflicts that may arise should be handled well

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situtation where more than one people comment on the doc and mess up the content.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues we'll be modifying the access rights of the google doc associated with that project.
*We'll by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table "assignments" and we have made a change to the schema of the table by adding a column "allow_anonymous_commenting" of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: _add_allow_anonymous_commenting_to_assignemnnts.rb
* The factories file in the spec has a variable added with the default value set as 'FALSE'
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T00:37:21Z

Sagupta: /* Project File and Database additions */ added the database change so far

=='''Expertiza Background'''==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by embedding Google docs into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza for using this feature.

== '''Key Points To Consider''' ==

The Google doc editor needs to be embedded in expertiza or it should be made as a pop up window
* The settings for the Google doc should be set to "anyone with link can comment"
* A peer reviewer need not login to Google to comment on the doc, and all peer reviewer comments must be anonymous
* If more than one user comment on the Google doc at the same time, any conflicts that may arise should be handled well

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situtation where more than one people comment on the doc and mess up the content.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*To address these two issues we'll be modifying the access rights of the google doc associated with that project.
*We'll by default assign all new users who access the page only the 'can comment' access right and only the author team will have 'can edit' rights.

[[File:can_comment.png]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table "assignments" and we have made a change to the schema of the table by adding a column "allow_anonymous_commenting" of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-10-29T03:45:03Z

Sagupta:

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza Background==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

[[File:rsz_unnamed.png]]
The Code Climate Grade Before Regactoring

[[File:rsz_1after.png]]
The Code Climate Grade After Regactoring
== Testing Details==

====UI Testing====

Login into Expertiza as a student or an instructor. Go to an assignment which has some reviews for a previous project and click on view scores. The total score for a review is calculated on the fly using this module. You will be able to see the average score that each reviewer gave you on the top right of your page. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality.

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

File:Rsz 1after.png

2016-10-29T03:42:50Z

Sagupta: After refactoring code grade

After refactoring code grade

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-10-29T03:39:23Z

Sagupta:

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza Background==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

[[File:rsz_unnamed.png]]

== Testing Details==

====UI Testing====

Login into Expertiza as a student or an instructor. Go to an assignment which has some reviews for a previous project and click on view scores. The total score for a review is calculated on the fly using this module. You will be able to see the average score that each reviewer gave you on the top right of your page. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality.

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

File:Rsz unnamed.png

2016-10-29T03:38:14Z

Sagupta: Code Climate Grade Before Refactoring

Code Climate Grade Before Refactoring

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-10-29T03:31:48Z

Sagupta:

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza Background==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

== Testing Details==

====UI Testing====

Login into Expertiza as a student or an instructor. Go to an assignment which has some reviews for a previous project and click on view scores. The total score for a review is calculated on the fly using this module. You will be able to see the average score that each reviewer gave you on the top right of your page. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality.

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-10-29T03:30:46Z

Sagupta:

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza Background==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

== Testing Details==

UI Testing

Login into Expertiza as a student or an instructor. Go to an assignment which has some reviews for a previous project and click on view scores. The total score for a review is calculated on the fly using this module. You will be able to see the average score that each reviewer gave you on the top right of your page. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality.

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-10-29T03:28:40Z

Sagupta:

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza Background==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

== Testing Details==

== UI Testing ==

Login into Expertiza as a student or an instructor. Go to an assignment which has some reviews for a previous project and click on view scores. The total score for a review is calculated on the fly using this module. You will be able to see the average score that each reviewer gave you on the top right of your page. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality.

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-10-29T03:27:37Z

Sagupta: /* Scope for future improvement */

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza Background==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

== Testing Details==

=== UI Testing ===

Login into Expertiza as a student or an instructor. Go to an assignment which has some reviews for a previous project and click on view scores. The total score for a review is calculated on the fly using this module. You will be able to see the average score that each reviewer gave you on the top right of your page. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality.

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-10-29T03:27:17Z

Sagupta:

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza Background==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

== Testing Details==

=== UI Testing ===

Login into Expertiza as a student or an instructor. Go to an assignment which has some reviews for a previous project and click on view scores. The total score for a review is calculated on the fly using this module. You will be able to see the average score that each reviewer gave you on the top right of your page. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality.

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".
Perceived
ABC