Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2019 - E1978. Fix issues related to deadlines and late policies

2019-12-07T06:38:41Z

Nnegi2: /* Approach & Fix */

This page gives a description of the issues and the approach towards solving them in the E1978. Fix issues related to deadlines and late policies project.
 

__TOC__

===Problem Description===
----
Expertiza can automatically deduct points if a student is late in performing some action (e.g., submitting or reviewing). This is implemented by defining a new “late policy” and applying it to the assignment. Late policies are managed on the Due dates tab of assignment creation (or editing).

 
====Issues with the Current Implementation====
----
The current implementation of Expertiza has the following Issues:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”. To avoid confusion, use “late policy” exclusively.
 

[[File:Qissue1.png]]

* '''Issue 2''' - Late policies cannot be created without raising an error.
 

[[File:Qissue2.png]]

* '''Issue 3''' - After creating a late policy, the “back” link does not take the user back to editing the assignment.
 

[[File:Qissue31.png]]

[[File:Qissue32.png]]

* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work. Expertiza has a way of adjusting due dates for a new assignment. If a new assignment is created by copying an old assignment, the due dates are copied too. It is likely that sometimes the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.) is wished. To avoid the need to edit all the deadlines manually, Expertiza has a date updater. However, it does not work.
 

[[File:Issue41.png]]

[[File:Issue42.png]]

* '''Issue 5''' - Neither late_policy.rb nor late_policies_controller.rb have any tests at all.

 

===Project Scope===
----
 
[[File:Rsz late policy.png]]
 
Issues described in the above section all exist in the Due Dates tab on the Edit Assignment page.
* '''Issue 1''' - The scope of this issue is to change "penalty policy" to "late policy" on all the relevant UI screens (app/views/late_policies).
* '''Issue 2''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 3''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 4''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 5''' - The scope of this issue is to write test cases for late_policies_controller.rb and late_policy.rb.

===Approach & Fix===

----
<h3>Issue 1: Renaming penalty policy to late policy</h3>

<ul>
<li>Renaming done on the UI as well as on the backend</li>
<li>Varible names refactored appropritely</li>
<li>Flash messages changed accordingly</li>
</ul>

<h3>Issue 2: Late policies cannot be created without raising an error</h3>

The error which is raised is due to the following validation present in the model late_policy.rb.
 
<h6>validates :max_penalty, numericality: {less_than: 50}</h6>


<ul>
<li>After discussing with professor we have decided to increase the max penalty limit to 100</li>
<li>Added a flash error message in the create function of late_policies_controller.rb</li>
</ul>
if params[:late_policy][:max_penalty].to_i>=100
flash[:error] = "Maximum penalty cannot be greater than or equal to 100"
invalid_max_penalty = true;
end

<h3>Issue 3: After creating a late policy, the “back” link does not take the user back to editing the assignment.</h3>

<ul>
<li>Added a back link in which redirects the user to edit assignment page.</li>
<li>Saved the assignment object in a session variable when the user clicks on the the edit asignment icon</li>
<li>We also added a back button on index page since there was no direct way of going back to edit assignment page once a late policy was created.</li>
<li>We also added padding between the edit and delete links on index page</li>
</ul>
<%= link_to 'Back', :controller=> 'assignments', :action => 'edit', :id => session[:assignment] %>

<h3>Issue 4: The "+" and "-" buttons for Show/Hide Date Updater do not work.</h3>

While testing this issue we noticed that the functionality was working perfectly fine, however, it was not user friendly.
<ul>
<li>We decided to add a tooltip icon explaining how this functionality works</li>
<li>We also inproved its UI by adding the alignment and padding.</li>
</ul>

<h3>Issue 5: Neither late_policy.rb nor late_policies_controller.rb have any tests at all. Define a test plan, and write appropriate tests for these classes.</h3>
<ul>
<li>Added test file late_policies_controller_spec.rb with appropriate test cases</li>
<li>Added test file late_policies_spec.rb with appropriate test cases
</ul>

 

===Expected Results===
----
* '''Issue 1''' - Once this issue is fixed, the Due Dates tab while editing an assignment will have no ambiguity between "late policy" and "penalty policy", as "late policy" will be used exclusively.
 
[[File:Hitissue11.png]]
 
* '''Issue 2''' - Once this issue is fixed, late policies can be created and saved successfully without raising the "The following error occurred while saving the penalty policy:" error.
 
[[File:Hitissue2.png]]
 
* '''Issue 3''' - Once this issue is fixed, the back link after creating a late policy will rightly take the user to the General tab on the Edit Assignment page.
 
[[File:Hitissue3.png]]
 
* '''Issue 4''' - Once this issue is fixed, "+" and "-" buttons for Show/Hide Date Updater will work and update all the dates relative to the first date keeping the days gap between all the dates the same as before.
 
[[File:Hitissue4.png]]
 
* '''Issue 5''' - The code coverage will definitely increase once tests for late_policy.rb and late_policies_controller.rb are written.
 
[[File:Hitissue5.png]]
 

 

===Test Plan===
----
'''''Before fix'''''
 
 
'''Manual Testing ()'''

Log in to Expertiza as an Instructor by entering the credentials: Username: instructor6, Password: password

The following route is common to testing all the issues:

Welcome page -> Manage Assignments -> Select a Course -> Select Edit option for any assignment -> Edit Assignment (General) ->

'''Issue 1''' - <pre> Due Dates -> No 'penalty policy' on the page. </pre>

'''Issue 2''' - <pre> Due Dates -> New late policy -> Enter information and Create -> Late policy is successfully created and saved. </pre>

'''Issue 3''' - <pre> Due Dates -> New late policy -> Enter information and Create -> Back -> Edit Assignment (General) </pre>

'''Issue 4''' - <pre> Due Dates -> Show/Hide Date Updater -> Enter number of days -> Hit + / - </pre>

'''Automated Testing Using RSpec'''

We plan to create two new files, late_policy_spec.rb and late_policies_controller_spec.rb to write tests for late_policy.rb and late_policies_controller.rb repesctively.

'''Coverage'''

To make sure we are covering all of our code with test cases we will use the Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually running the test file, the SimpleCov gem will highlight the lines of code which are being covered by our test cases in green color, and for those which are not being covered in red.

 
'''''Afterfix'''''
 

To test the controller 'late_policies_controller.rb' and model 'late_policy.rb' we created 2 test files late_policy_spec.rb and late_policies_controller_spec.rb. To write test cases we used rspec functions and tested the functions on the basis of :
<ul>
<li>What they returned</li>
<li>Which page got rendered</li>
<li>Which flash error got produced</li>
<li>Which method got called</li>
</ul>
We also used stubbing and mocking functions to carry out our tests. After executing our tests we got an increase in the overall code coverage of over 0.5% for each file.
 
 
Here are the results of SimpleCov gem highlighting the code coverage of our tests.
 
[[File:Testplanyess.png]]
 
===Milestones===
----
'''11/01''' – Project Selection

'''11/11''' – Create Design Doc

'''11/15''' – setting up project environment and updating Design Doc

'''11/25''' – Fix Issues 1,2 and 3 with well-defined test cases

'''11/30''' – Fix issues 4 and 5 with well-defined test cases

'''12/04''' – Update design doc and create & upload video

'''12/06''' – Write tests for edge cases.

 

===Project Mentors===
----
* Edward Gehringer (efg@ncsu.edu)

* Ramya Vijayakumar (rvijaya4@ncsu.edu)

 

===Team Members===
----
* Rajit Bharambe (rbharam@ncsu.edu)

* Saahil Chawande (schawan@ncsu.edu)

* Natansh Negi (nnegi2@ncsu.edu)

* Hitarth Shah (hshah4@ncsu.edu)

===References===
----
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/rajitnb/expertiza GitHub Project Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]

CSC/ECE 517 Fall 2019 - E1978. Fix issues related to deadlines and late policies

2019-12-07T03:52:52Z

Nnegi2: /* Test Plan */

This page gives a description of the issues and the approach towards solving them in the E1978. Fix issues related to deadlines and late policies project.
 

__TOC__

===Problem Description===
----
Expertiza can automatically deduct points if a student is late in performing some action (e.g., submitting or reviewing). This is implemented by defining a new “late policy” and applying it to the assignment. Late policies are managed on the Due dates tab of assignment creation (or editing).

 
====Issues with the Current Implementation====
----
The current implementation of Expertiza has the following Issues:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”. To avoid confusion, use “late policy” exclusively.
 

[[File:Qissue1.png]]

* '''Issue 2''' - Late policies cannot be created without raising an error.
 

[[File:Qissue2.png]]

* '''Issue 3''' - After creating a late policy, the “back” link does not take the user back to editing the assignment.
 

[[File:Qissue31.png]]

[[File:Qissue32.png]]

* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work. Expertiza has a way of adjusting due dates for a new assignment. If a new assignment is created by copying an old assignment, the due dates are copied too. It is likely that sometimes the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.) is wished. To avoid the need to edit all the deadlines manually, Expertiza has a date updater. However, it does not work.
 

[[File:Issue41.png]]

[[File:Issue42.png]]

* '''Issue 5''' - Neither late_policy.rb nor late_policies_controller.rb have any tests at all.

 

===Project Scope===
----

Issues described in the above section all exist in the Due Dates tab on the Edit Assignment page.
* '''Issue 1''' - The scope of this issue is to change "penalty policy" to "late policy" on all the relevant UI screens (app/views/late_policies).
* '''Issue 2''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 3''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 4''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 5''' - The scope of this issue is to write test cases for late_policies_controller.rb and late_policy.rb.

===Approach & Fix===
----
<h3>Issue 1: Renaming penalty policy to late policy</h3>

<ul>
<li>Renaming done on the UI as well as on the backend</li>
<li>Varible names refactored appropritely</li>
<li>Flash messages changed accordingly</li>
</ul>

<h3>Issue 2: Late policies cannot be created without raising an error</h3>

The error which is raised is due to the following validation present in the model late_policy.rb.
 
<h6>validates :max_penalty, numericality: {less_than: 50}</h6>


<ul>
<li>After discussing with professor we have decided to increase the max penalty limit to 100</li>
<li>Added a flash error message in the create function of late_policies_controller.rb</li>
</ul>
if params[:late_policy][:max_penalty].to_i>=50
flash[:error] = "Maximum penalty cannot be greater than or equal to 50"
invalid_max_penalty = true;
end

<h3>Issue 3: After creating a late policy, the “back” link does not take the user back to editing the assignment.</h3>

<ul>
<li>Added a back link in which redirects the user to edit assignment page.</li>
<li>Saved the assignment object in a session variable when the user clicks on the the edit asignment icon</li>
<li>We also added a back button on index page since there was no direct way of going back to edit assignment page once a late policy was created.</li>
<li>We also added padding between the edit and delete links on index page</li>
</ul>
<%= link_to 'Back', :controller=> 'assignments', :action => 'edit', :id => session[:assignment] %>

<h3>Issue 4: The "+" and "-" buttons for Show/Hide Date Updater do not work.</h3>

While testing this issue we noticed that the functionality was working perfectly fine, however, it was not user friendly.
<ul>
<li>We decided to add a tooltip icon explaining how this functionality works</li>
<li>We also inproved its UI by adding the alignment and padding.</li>
</ul>

<h3>Issue 5: Neither late_policy.rb nor late_policies_controller.rb have any tests at all. Define a test plan, and write appropriate tests for these classes.</h3>
<ul>
<li>Added test file late_policies_controller_spec.rb with appropriate test cases</li>
<li>Added test file late_policies_spec.rb with appropriate test cases
</ul>

 

===Expected Results===
----
* '''Issue 1''' - Once this issue is fixed, the Due Dates tab while editing an assignment will have no ambiguity between "late policy" and "penalty policy", as "late policy" will be used exclusively.
* '''Issue 2''' - Once this issue is fixed, late policies can be created and saved successfully without raising the "The following error occurred while saving the penalty policy:" error.
* '''Issue 3''' - Once this issue is fixed, the back link after creating a late policy will rightly take the user to the General tab on the Edit Assignment page.
* '''Issue 4''' - Once this issue is fixed, "+" and "-" buttons for Show/Hide Date Updater will work and update all the dates relative to the first date keeping the days gap between all the dates the same as before.
* '''Issue 5''' - The code coverage will definitely increase once tests for late_policy.rb and late_policies_controller.rb are written.
 

[[File:Rsz late policy.png]]

===Test Plan===
----
'''''Before fix'''''
 
 
'''Manual Testing ()'''

Log in to Expertiza as an Instructor by entering the credentials: Username: instructor6, Password: password

The following route is common to testing all the issues:

Welcome page -> Manage Assignments -> Select a Course -> Select Edit option for any assignment -> Edit Assignment (General) ->

'''Issue 1''' - <pre> Due Dates -> No 'penalty policy' on the page. </pre>

'''Issue 2''' - <pre> Due Dates -> New late policy -> Enter information and Create -> Late policy is successfully created and saved. </pre>

'''Issue 3''' - <pre> Due Dates -> New late policy -> Enter information and Create -> Back -> Edit Assignment (General) </pre>

'''Issue 4''' - <pre> Due Dates -> Show/Hide Date Updater -> Enter number of days -> Hit + / - </pre>

'''Automated Testing Using RSpec'''

We plan to create two new files, late_policy_spec.rb and late_policies_controller_spec.rb to write tests for late_policy.rb and late_policies_controller.rb repesctively.

'''Coverage'''

To make sure we are covering all of our code with test cases we will use the Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually running the test file, the SimpleCov gem will highlight the lines of code which are being covered by our test cases in green color, and for those which are not being covered in red.

 
'''''Afterfix'''''
 

To test the controller 'late_policies_controller.rb' and model 'late_policy.rb' we created 2 test files late_policy_spec.rb and late_policies_controller_spec.rb. To write test cases we used rspec functions and tested the functions on the basis of :
<ul>
<li>What they returned</li>
<li>Which page got rendered</li>
<li>Which flash error got produced</li>
<li>Which method got called</li>
</ul>
We also used stubbing and mocking functions to carry out our tests. After executing our tests we got an increase in the overall code coverage of over 0.5% for each file.
 
 
Here are the results of SimpleCov gem highlighting the code coverage of our tests.
 

===Milestones===
----
'''11/01''' – Project Selection

'''11/11''' – Create Design Doc

'''11/15''' – setting up project environment and updating Design Doc

'''11/25''' – Fix Issues 1,2 and 3 with well-defined test cases

'''11/30''' – Fix issues 4 and 5 with well-defined test cases

'''12/04''' – Update design doc and create & upload video

'''12/06''' – Write tests for edge cases.

 

===Project Mentors===
----
* Edward Gehringer (efg@ncsu.edu)

* Ramya Vijayakumar (rvijaya4@ncsu.edu)

 

===Team Members===
----
* Rajit Bharambe (rbharam@ncsu.edu)

* Saahil Chawande (schawan@ncsu.edu)

* Natansh Negi (nnegi2@ncsu.edu)

* Hitarth Shah (hshah4@ncsu.edu)

===References===
----
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/rajitnb/expertiza GitHub Project Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]

CSC/ECE 517 Fall 2019 - E1978. Fix issues related to deadlines and late policies

2019-12-07T03:37:54Z

Nnegi2: /* Approach & Fix */

This page gives a description of the issues and the approach towards solving them in the E1978. Fix issues related to deadlines and late policies project.
 

__TOC__

===Problem Description===
----
Expertiza can automatically deduct points if a student is late in performing some action (e.g., submitting or reviewing). This is implemented by defining a new “late policy” and applying it to the assignment. Late policies are managed on the Due dates tab of assignment creation (or editing).

 
====Issues with the Current Implementation====
----
The current implementation of Expertiza has the following Issues:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”. To avoid confusion, use “late policy” exclusively.
 

[[File:Qissue1.png]]

* '''Issue 2''' - Late policies cannot be created without raising an error.
 

[[File:Qissue2.png]]

* '''Issue 3''' - After creating a late policy, the “back” link does not take the user back to editing the assignment.
 

[[File:Qissue31.png]]

[[File:Qissue32.png]]

* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work. Expertiza has a way of adjusting due dates for a new assignment. If a new assignment is created by copying an old assignment, the due dates are copied too. It is likely that sometimes the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.) is wished. To avoid the need to edit all the deadlines manually, Expertiza has a date updater. However, it does not work.
 

[[File:Issue41.png]]

[[File:Issue42.png]]

* '''Issue 5''' - Neither late_policy.rb nor late_policies_controller.rb have any tests at all.

 

===Project Scope===
----

Issues described in the above section all exist in the Due Dates tab on the Edit Assignment page.
* '''Issue 1''' - The scope of this issue is to change "penalty policy" to "late policy" on all the relevant UI screens (app/views/late_policies).
* '''Issue 2''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 3''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 4''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 5''' - The scope of this issue is to write test cases for late_policies_controller.rb and late_policy.rb.

===Approach & Fix===
----
<h3>Issue 1: Renaming penalty policy to late policy</h3>

<ul>
<li>Renaming done on the UI as well as on the backend</li>
<li>Varible names refactored appropritely</li>
<li>Flash messages changed accordingly</li>
</ul>

<h3>Issue 2: Late policies cannot be created without raising an error</h3>

The error which is raised is due to the following validation present in the model late_policy.rb.
 
<h6>validates :max_penalty, numericality: {less_than: 50}</h6>


<ul>
<li>After discussing with professor we have decided to increase the max penalty limit to 100</li>
<li>Added a flash error message in the create function of late_policies_controller.rb</li>
</ul>
if params[:late_policy][:max_penalty].to_i>=50
flash[:error] = "Maximum penalty cannot be greater than or equal to 50"
invalid_max_penalty = true;
end

<h3>Issue 3: After creating a late policy, the “back” link does not take the user back to editing the assignment.</h3>

<ul>
<li>Added a back link in which redirects the user to edit assignment page.</li>
<li>Saved the assignment object in a session variable when the user clicks on the the edit asignment icon</li>
<li>We also added a back button on index page since there was no direct way of going back to edit assignment page once a late policy was created.</li>
<li>We also added padding between the edit and delete links on index page</li>
</ul>
<%= link_to 'Back', :controller=> 'assignments', :action => 'edit', :id => session[:assignment] %>

<h3>Issue 4: The "+" and "-" buttons for Show/Hide Date Updater do not work.</h3>

While testing this issue we noticed that the functionality was working perfectly fine, however, it was not user friendly.
<ul>
<li>We decided to add a tooltip icon explaining how this functionality works</li>
<li>We also inproved its UI by adding the alignment and padding.</li>
</ul>

<h3>Issue 5: Neither late_policy.rb nor late_policies_controller.rb have any tests at all. Define a test plan, and write appropriate tests for these classes.</h3>
<ul>
<li>Added test file late_policies_controller_spec.rb with appropriate test cases</li>
<li>Added test file late_policies_spec.rb with appropriate test cases
</ul>

 

===Expected Results===
----
* '''Issue 1''' - Once this issue is fixed, the Due Dates tab while editing an assignment will have no ambiguity between "late policy" and "penalty policy", as "late policy" will be used exclusively.
* '''Issue 2''' - Once this issue is fixed, late policies can be created and saved successfully without raising the "The following error occurred while saving the penalty policy:" error.
* '''Issue 3''' - Once this issue is fixed, the back link after creating a late policy will rightly take the user to the General tab on the Edit Assignment page.
* '''Issue 4''' - Once this issue is fixed, "+" and "-" buttons for Show/Hide Date Updater will work and update all the dates relative to the first date keeping the days gap between all the dates the same as before.
* '''Issue 5''' - The code coverage will definitely increase once tests for late_policy.rb and late_policies_controller.rb are written.
 

[[File:Rsz late policy.png]]

===Test Plan===
----

'''Manual Testing'''

Log in to Expertiza as an Instructor by entering the credentials: Username: instructor6, Password: password

The following route is common to testing all the issues:

Welcome page -> Manage Assignments -> Select a Course -> Select Edit option for any assignment -> Edit Assignment (General) ->

'''Issue 1''' - <pre> Due Dates -> No 'penalty policy' on the page. </pre>

'''Issue 2''' - <pre> Due Dates -> New late policy -> Enter information and Create -> Late policy is successfully created and saved. </pre>

'''Issue 3''' - <pre> Due Dates -> New late policy -> Enter information and Create -> Back -> Edit Assignment (General) </pre>

'''Issue 4''' - <pre> Due Dates -> Show/Hide Date Updater -> Enter number of days -> Hit + / - </pre>

'''Automated Testing Using RSpec'''

We plan to create two new files, late_policy_spec.rb and late_policies_controller_spec.rb to write tests for late_policy.rb and late_policies_controller.rb repesctively.

'''Coverage'''

To make sure we are covering all of our code (100%) with test cases we will use the Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually running the test file, the SimpleCov gem will highlight the lines of code which are being covered by our test cases in green color, and for those which are not being covered in red.

 

===Milestones===
----
'''11/01''' – Project Selection

'''11/11''' – Create Design Doc

'''11/15''' – setting up project environment and updating Design Doc

'''11/25''' – Fix Issues 1,2 and 3 with well-defined test cases

'''11/30''' – Fix issues 4 and 5 with well-defined test cases

'''12/04''' – Update design doc and create & upload video

'''12/06''' – Write tests for edge cases.

 

===Project Mentors===
----
* Edward Gehringer (efg@ncsu.edu)

* Ramya Vijayakumar (rvijaya4@ncsu.edu)

 

===Team Members===
----
* Rajit Bharambe (rbharam@ncsu.edu)

* Saahil Chawande (schawan@ncsu.edu)

* Natansh Negi (nnegi2@ncsu.edu)

* Hitarth Shah (hshah4@ncsu.edu)

===References===
----
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/rajitnb/expertiza GitHub Project Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]

CSC/ECE 517 Fall 2019 - E1978. Fix issues related to deadlines and late policies

2019-12-07T03:37:38Z

Nnegi2: /* Approach & Fix */

This page gives a description of the issues and the approach towards solving them in the E1978. Fix issues related to deadlines and late policies project.
 

__TOC__

===Problem Description===
----
Expertiza can automatically deduct points if a student is late in performing some action (e.g., submitting or reviewing). This is implemented by defining a new “late policy” and applying it to the assignment. Late policies are managed on the Due dates tab of assignment creation (or editing).

 
====Issues with the Current Implementation====
----
The current implementation of Expertiza has the following Issues:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”. To avoid confusion, use “late policy” exclusively.
 

[[File:Qissue1.png]]

* '''Issue 2''' - Late policies cannot be created without raising an error.
 

[[File:Qissue2.png]]

* '''Issue 3''' - After creating a late policy, the “back” link does not take the user back to editing the assignment.
 

[[File:Qissue31.png]]

[[File:Qissue32.png]]

* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work. Expertiza has a way of adjusting due dates for a new assignment. If a new assignment is created by copying an old assignment, the due dates are copied too. It is likely that sometimes the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.) is wished. To avoid the need to edit all the deadlines manually, Expertiza has a date updater. However, it does not work.
 

[[File:Issue41.png]]

[[File:Issue42.png]]

* '''Issue 5''' - Neither late_policy.rb nor late_policies_controller.rb have any tests at all.

 

===Project Scope===
----

Issues described in the above section all exist in the Due Dates tab on the Edit Assignment page.
* '''Issue 1''' - The scope of this issue is to change "penalty policy" to "late policy" on all the relevant UI screens (app/views/late_policies).
* '''Issue 2''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 3''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 4''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 5''' - The scope of this issue is to write test cases for late_policies_controller.rb and late_policy.rb.

===Approach & Fix===
----
<h3>Issue 1: Renaming penalty policy to late policy</h3>

<ul>
<li>Renaming done on the UI as well as on the backend</li>
<li>Varible names refactored appropritely</li>
<li>Flash messages changed accordingly</li>
</ul>

<h3>Issue 2: Late policies cannot be created without raising an error</h3>

The error which is raised is due to the following validation present in the model late_policy.rb.
 
<h6>validates :max_penalty, numericality: {less_than: 50}</h6>


<ul>
<li>After discussing with professor we have decided to increase the max penalty limit to 100</li>
<li>Added a flash error message in the create function of late_policies_controller.rb</li>
</ul>
if params[:late_policy][:max_penalty].to_i>=50
flash[:error] = "Maximum penalty cannot be greater than or equal to 50"
invalid_max_penalty = true;
end

<h3>Issue 3: After creating a late policy, the “back” link does not take the user back to editing the assignment.</h3>

<ul>
<li>Added a back link in which redirects the user to edit assignment page.</li>
<li>Saved the assignment object in a session variable when the user clicks on the the edit asignment icon</li>
<li>We also added a back button on index page since there was no direct way of going back to edit assignment page once a late policy was created.</li>
<li>We also added padding between the edit and delete links on index page<li>
</ul>
<%= link_to 'Back', :controller=> 'assignments', :action => 'edit', :id => session[:assignment] %>

<h3>Issue 4: The "+" and "-" buttons for Show/Hide Date Updater do not work.</h3>

While testing this issue we noticed that the functionality was working perfectly fine, however, it was not user friendly.
<ul>
<li>We decided to add a tooltip icon explaining how this functionality works</li>
<li>We also inproved its UI by adding the alignment and padding.</li>
</ul>

<h3>Issue 5: Neither late_policy.rb nor late_policies_controller.rb have any tests at all. Define a test plan, and write appropriate tests for these classes.</h3>
<ul>
<li>Added test file late_policies_controller_spec.rb with appropriate test cases</li>
<li>Added test file late_policies_spec.rb with appropriate test cases
</ul>

 

===Expected Results===
----
* '''Issue 1''' - Once this issue is fixed, the Due Dates tab while editing an assignment will have no ambiguity between "late policy" and "penalty policy", as "late policy" will be used exclusively.
* '''Issue 2''' - Once this issue is fixed, late policies can be created and saved successfully without raising the "The following error occurred while saving the penalty policy:" error.
* '''Issue 3''' - Once this issue is fixed, the back link after creating a late policy will rightly take the user to the General tab on the Edit Assignment page.
* '''Issue 4''' - Once this issue is fixed, "+" and "-" buttons for Show/Hide Date Updater will work and update all the dates relative to the first date keeping the days gap between all the dates the same as before.
* '''Issue 5''' - The code coverage will definitely increase once tests for late_policy.rb and late_policies_controller.rb are written.
 

[[File:Rsz late policy.png]]

===Test Plan===
----

'''Manual Testing'''

Log in to Expertiza as an Instructor by entering the credentials: Username: instructor6, Password: password

The following route is common to testing all the issues:

Welcome page -> Manage Assignments -> Select a Course -> Select Edit option for any assignment -> Edit Assignment (General) ->

'''Issue 1''' - <pre> Due Dates -> No 'penalty policy' on the page. </pre>

'''Issue 2''' - <pre> Due Dates -> New late policy -> Enter information and Create -> Late policy is successfully created and saved. </pre>

'''Issue 3''' - <pre> Due Dates -> New late policy -> Enter information and Create -> Back -> Edit Assignment (General) </pre>

'''Issue 4''' - <pre> Due Dates -> Show/Hide Date Updater -> Enter number of days -> Hit + / - </pre>

'''Automated Testing Using RSpec'''

We plan to create two new files, late_policy_spec.rb and late_policies_controller_spec.rb to write tests for late_policy.rb and late_policies_controller.rb repesctively.

'''Coverage'''

To make sure we are covering all of our code (100%) with test cases we will use the Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually running the test file, the SimpleCov gem will highlight the lines of code which are being covered by our test cases in green color, and for those which are not being covered in red.

 

===Milestones===
----
'''11/01''' – Project Selection

'''11/11''' – Create Design Doc

'''11/15''' – setting up project environment and updating Design Doc

'''11/25''' – Fix Issues 1,2 and 3 with well-defined test cases

'''11/30''' – Fix issues 4 and 5 with well-defined test cases

'''12/04''' – Update design doc and create & upload video

'''12/06''' – Write tests for edge cases.

 

===Project Mentors===
----
* Edward Gehringer (efg@ncsu.edu)

* Ramya Vijayakumar (rvijaya4@ncsu.edu)

 

===Team Members===
----
* Rajit Bharambe (rbharam@ncsu.edu)

* Saahil Chawande (schawan@ncsu.edu)

* Natansh Negi (nnegi2@ncsu.edu)

* Hitarth Shah (hshah4@ncsu.edu)

===References===
----
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/rajitnb/expertiza GitHub Project Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]

CSC/ECE 517 Fall 2019 - E1978. Fix issues related to deadlines and late policies

2019-12-07T03:31:35Z

Nnegi2: /* Approach & Fix */

This page gives a description of the issues and the approach towards solving them in the E1978. Fix issues related to deadlines and late policies project.
 

__TOC__

===Problem Description===
----
Expertiza can automatically deduct points if a student is late in performing some action (e.g., submitting or reviewing). This is implemented by defining a new “late policy” and applying it to the assignment. Late policies are managed on the Due dates tab of assignment creation (or editing).

 
====Issues with the Current Implementation====
----
The current implementation of Expertiza has the following Issues:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”. To avoid confusion, use “late policy” exclusively.
 

[[File:Qissue1.png]]

* '''Issue 2''' - Late policies cannot be created without raising an error.
 

[[File:Qissue2.png]]

* '''Issue 3''' - After creating a late policy, the “back” link does not take the user back to editing the assignment.
 

[[File:Qissue31.png]]

[[File:Qissue32.png]]

* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work. Expertiza has a way of adjusting due dates for a new assignment. If a new assignment is created by copying an old assignment, the due dates are copied too. It is likely that sometimes the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.) is wished. To avoid the need to edit all the deadlines manually, Expertiza has a date updater. However, it does not work.
 

[[File:Issue41.png]]

[[File:Issue42.png]]

* '''Issue 5''' - Neither late_policy.rb nor late_policies_controller.rb have any tests at all.

 

===Project Scope===
----

Issues described in the above section all exist in the Due Dates tab on the Edit Assignment page.
* '''Issue 1''' - The scope of this issue is to change "penalty policy" to "late policy" on all the relevant UI screens (app/views/late_policies).
* '''Issue 2''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 3''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 4''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 5''' - The scope of this issue is to write test cases for late_policies_controller.rb and late_policy.rb.

===Approach & Fix===
----
<h3>Issue 1: Renaming penalty policy to late policy</h3>

<ul>
<li>Renaming done on the UI as well as on the backend</li>
<li>Varible names refactored appropritely</li>
<li>Flash messages changed accordingly</li>
</ul>

<h3>Issue 2: Late policies cannot be created without raising an error</h3>

The error which is raised is due to the following validation present in the model late_policy.rb.
 
<h6>validates :max_penalty, numericality: {less_than: 50}</h6>


<ul>
<li>After discussing with professor we have decided to increase the max penalty limit to 100</li>
<li>Added a flash error message in the create function of late_policies_controller.rb</li>
</ul>
if params[:late_policy][:max_penalty].to_i>=50
flash[:error] = "Maximum penalty cannot be greater than or equal to 50"
invalid_max_penalty = true;
end

<h3>Issue 3: After creating a late policy, the “back” link does not take the user back to editing the assignment.</h3>

<ul>
<li>Added a back link in which redirects the user to edit assignment page.</li>
<li>Saved the assignment object in a session variable when the user clicks on the the edit asignment icon</li>
<li>We also added a back button on index page since there was no direct way of going back to edit assignment page once a late policy was created</li>
</ul>
<%= link_to 'Back', :controller=> 'assignments', :action => 'edit', :id => session[:assignment] %>

<h3>Issue 4: The "+" and "-" buttons for Show/Hide Date Updater do not work.</h3>

While testing this issue we noticed that the functionality was working perfectly fine, however, it was not user friendly.
<ul>
<li>We decided to add a tooltip icon explaining how this functionality works</li>
<li>We also inproved its UI by adding the alignment and padding.</li>
</ul>

<h3>Issue 5: Neither late_policy.rb nor late_policies_controller.rb have any tests at all. Define a test plan, and write appropriate tests for these classes.</h3>
<ul>
<li>Added test file late_policies_controller_spec.rb with appropriate test cases</li>
<li>Added test file late_policies_spec.rb with appropriate test cases
<ul>

===Expected Results===
----
* '''Issue 1''' - Once this issue is fixed, the Due Dates tab while editing an assignment will have no ambiguity between "late policy" and "penalty policy", as "late policy" will be used exclusively.
* '''Issue 2''' - Once this issue is fixed, late policies can be created and saved successfully without raising the "The following error occurred while saving the penalty policy:" error.
* '''Issue 3''' - Once this issue is fixed, the back link after creating a late policy will rightly take the user to the General tab on the Edit Assignment page.
* '''Issue 4''' - Once this issue is fixed, "+" and "-" buttons for Show/Hide Date Updater will work and update all the dates relative to the first date keeping the days gap between all the dates the same as before.
* '''Issue 5''' - The code coverage will definitely increase once tests for late_policy.rb and late_policies_controller.rb are written.
 

[[File:Rsz late policy.png]]

===Test Plan===
----

'''Manual Testing'''

Log in to Expertiza as an Instructor by entering the credentials: Username: instructor6, Password: password

The following route is common to testing all the issues:

Welcome page -> Manage Assignments -> Select a Course -> Select Edit option for any assignment -> Edit Assignment (General) ->

'''Issue 1''' - <pre> Due Dates -> No 'penalty policy' on the page. </pre>

'''Issue 2''' - <pre> Due Dates -> New late policy -> Enter information and Create -> Late policy is successfully created and saved. </pre>

'''Issue 3''' - <pre> Due Dates -> New late policy -> Enter information and Create -> Back -> Edit Assignment (General) </pre>

'''Issue 4''' - <pre> Due Dates -> Show/Hide Date Updater -> Enter number of days -> Hit + / - </pre>

'''Automated Testing Using RSpec'''

We plan to create two new files, late_policy_spec.rb and late_policies_controller_spec.rb to write tests for late_policy.rb and late_policies_controller.rb repesctively.

'''Coverage'''

To make sure we are covering all of our code (100%) with test cases we will use the Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually running the test file, the SimpleCov gem will highlight the lines of code which are being covered by our test cases in green color, and for those which are not being covered in red.

 

===Milestones===
----
'''11/01''' – Project Selection

'''11/11''' – Create Design Doc

'''11/15''' – setting up project environment and updating Design Doc

'''11/25''' – Fix Issues 1,2 and 3 with well-defined test cases

'''11/30''' – Fix issues 4 and 5 with well-defined test cases

'''12/04''' – Update design doc and create & upload video

'''12/06''' – Write tests for edge cases.

 

===Project Mentors===
----
* Edward Gehringer (efg@ncsu.edu)

* Ramya Vijayakumar (rvijaya4@ncsu.edu)

 

===Team Members===
----
* Rajit Bharambe (rbharam@ncsu.edu)

* Saahil Chawande (schawan@ncsu.edu)

* Natansh Negi (nnegi2@ncsu.edu)

* Hitarth Shah (hshah4@ncsu.edu)

===References===
----
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/rajitnb/expertiza GitHub Project Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]

CSC/ECE 517 Fall 2019 - E1978. Fix issues related to deadlines and late policies

2019-12-07T03:31:03Z

Nnegi2: /* Approach */

This page gives a description of the issues and the approach towards solving them in the E1978. Fix issues related to deadlines and late policies project.
 

__TOC__

===Problem Description===
----
Expertiza can automatically deduct points if a student is late in performing some action (e.g., submitting or reviewing). This is implemented by defining a new “late policy” and applying it to the assignment. Late policies are managed on the Due dates tab of assignment creation (or editing).

 
====Issues with the Current Implementation====
----
The current implementation of Expertiza has the following Issues:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”. To avoid confusion, use “late policy” exclusively.
 

[[File:Qissue1.png]]

* '''Issue 2''' - Late policies cannot be created without raising an error.
 

[[File:Qissue2.png]]

* '''Issue 3''' - After creating a late policy, the “back” link does not take the user back to editing the assignment.
 

[[File:Qissue31.png]]

[[File:Qissue32.png]]

* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work. Expertiza has a way of adjusting due dates for a new assignment. If a new assignment is created by copying an old assignment, the due dates are copied too. It is likely that sometimes the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.) is wished. To avoid the need to edit all the deadlines manually, Expertiza has a date updater. However, it does not work.
 

[[File:Issue41.png]]

[[File:Issue42.png]]

* '''Issue 5''' - Neither late_policy.rb nor late_policies_controller.rb have any tests at all.

 

===Project Scope===
----

Issues described in the above section all exist in the Due Dates tab on the Edit Assignment page.
* '''Issue 1''' - The scope of this issue is to change "penalty policy" to "late policy" on all the relevant UI screens (app/views/late_policies).
* '''Issue 2''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 3''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 4''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 5''' - The scope of this issue is to write test cases for late_policies_controller.rb and late_policy.rb.

===Approach & Fix===
----
 
<h3>Issue 1: Renaming penalty policy to late policy</h3>

<ul>
<li>Renaming done on the UI as well as on the backend</li>
<li>Varible names refactored appropritely</li>
<li>Flash messages changed accordingly</li>
</ul>

<h3>Issue 2: Late policies cannot be created without raising an error</h3>

The error which is raised is due to the following validation present in the model late_policy.rb.
 
<h6>validates :max_penalty, numericality: {less_than: 50}</h6>


<ul>
<li>After discussing with professor we have decided to increase the max penalty limit to 100</li>
<li>Added a flash error message in the create function of late_policies_controller.rb</li>
</ul>
if params[:late_policy][:max_penalty].to_i>=50
flash[:error] = "Maximum penalty cannot be greater than or equal to 50"
invalid_max_penalty = true;
end

<h3>Issue 3: After creating a late policy, the “back” link does not take the user back to editing the assignment.</h3>

<ul>
<li>Added a back link in which redirects the user to edit assignment page.</li>
<li>Saved the assignment object in a session variable when the user clicks on the the edit asignment icon</li>
<li>We also added a back button on index page since there was no direct way of going back to edit assignment page once a late policy was created</li>
</ul>
<%= link_to 'Back', :controller=> 'assignments', :action => 'edit', :id => session[:assignment] %>

<h3>Issue 4: The "+" and "-" buttons for Show/Hide Date Updater do not work.</h3>

While testing this issue we noticed that the functionality was working perfectly fine, however, it was not user friendly.
<ul>
<li>We decided to add a tooltip icon explaining how this functionality works</li>
<li>We also inproved its UI by adding the alignment and padding.</li>
</ul>

<h3>Issue 5: Neither late_policy.rb nor late_policies_controller.rb have any tests at all. Define a test plan, and write appropriate tests for these classes.</h3>
<ul>
<li>Added test file late_policies_controller_spec.rb with appropriate test cases</li>
<li>Added test file late_policies_spec.rb with appropriate test cases
<ul>

===Expected Results===
----
* '''Issue 1''' - Once this issue is fixed, the Due Dates tab while editing an assignment will have no ambiguity between "late policy" and "penalty policy", as "late policy" will be used exclusively.
* '''Issue 2''' - Once this issue is fixed, late policies can be created and saved successfully without raising the "The following error occurred while saving the penalty policy:" error.
* '''Issue 3''' - Once this issue is fixed, the back link after creating a late policy will rightly take the user to the General tab on the Edit Assignment page.
* '''Issue 4''' - Once this issue is fixed, "+" and "-" buttons for Show/Hide Date Updater will work and update all the dates relative to the first date keeping the days gap between all the dates the same as before.
* '''Issue 5''' - The code coverage will definitely increase once tests for late_policy.rb and late_policies_controller.rb are written.
 

[[File:Rsz late policy.png]]

===Test Plan===
----

'''Manual Testing'''

Log in to Expertiza as an Instructor by entering the credentials: Username: instructor6, Password: password

The following route is common to testing all the issues:

Welcome page -> Manage Assignments -> Select a Course -> Select Edit option for any assignment -> Edit Assignment (General) ->

'''Issue 1''' - <pre> Due Dates -> No 'penalty policy' on the page. </pre>

'''Issue 2''' - <pre> Due Dates -> New late policy -> Enter information and Create -> Late policy is successfully created and saved. </pre>

'''Issue 3''' - <pre> Due Dates -> New late policy -> Enter information and Create -> Back -> Edit Assignment (General) </pre>

'''Issue 4''' - <pre> Due Dates -> Show/Hide Date Updater -> Enter number of days -> Hit + / - </pre>

'''Automated Testing Using RSpec'''

We plan to create two new files, late_policy_spec.rb and late_policies_controller_spec.rb to write tests for late_policy.rb and late_policies_controller.rb repesctively.

'''Coverage'''

To make sure we are covering all of our code (100%) with test cases we will use the Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually running the test file, the SimpleCov gem will highlight the lines of code which are being covered by our test cases in green color, and for those which are not being covered in red.

 

===Milestones===
----
'''11/01''' – Project Selection

'''11/11''' – Create Design Doc

'''11/15''' – setting up project environment and updating Design Doc

'''11/25''' – Fix Issues 1,2 and 3 with well-defined test cases

'''11/30''' – Fix issues 4 and 5 with well-defined test cases

'''12/04''' – Update design doc and create & upload video

'''12/06''' – Write tests for edge cases.

 

===Project Mentors===
----
* Edward Gehringer (efg@ncsu.edu)

* Ramya Vijayakumar (rvijaya4@ncsu.edu)

 

===Team Members===
----
* Rajit Bharambe (rbharam@ncsu.edu)

* Saahil Chawande (schawan@ncsu.edu)

* Natansh Negi (nnegi2@ncsu.edu)

* Hitarth Shah (hshah4@ncsu.edu)

===References===
----
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/rajitnb/expertiza GitHub Project Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]

CSC/ECE 517 Fall 2019 - E1978. Fix issues related to deadlines and late policies

2019-11-11T03:22:42Z

Nnegi2: /* Approach */

==Fix issues related to deadlines and late policies==

This page gives a description of the issues and the approach towards solving them in the E1978. Fix issues related to deadlines and late policies project.

__TOC__

===Problem Description===
----
Expertiza can automatically deduct points if a student is late in performing some action (e.g., submitting or reviewing). This is implemented by defining a new “late policy” and applying it to the assignment. Late policies are managed on the Due dates tab of assignment creation (or editing).

 
====Issues with the Current Implementation====
----
The current implementation of Expertiza has the following Issues:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”. To avoid confusion, use “late policy” exclusively.
* '''Issue 2''' - Late policies cannot be created without raising an error.
* '''Issue 3''' - After creating a late policy, the “back” link does not take the user back to editing the assignment.
* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work. Expertiza has a way of adjusting due dates for a new assignment. If a new assignment is created by copying an old assignment, the due dates are copied too. It is likely that sometimes the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.) is wished. To avoid the need to edit all the deadlines manually, Expertiza has a date updater. However, it does not work.
* '''Issue 5''' - Neither late_policy.rb nor late_policies_controller.rb have any tests at all.

[[File:Upload.png]]

 

===Project Scope===
----

Issues described in the above section all exist in the Due Dates tab on the Edit Assignment page.
* '''Issue 1''' - The scope of this issue is to change "penalty policy" to "late policy" on all the relevant UI screens (app/views/late_policies).
* '''Issue 2''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 3''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 4''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 5''' - The scope of this issue is to write test cases for late_policies_controller.rb and late_policy.rb.

===Approach===
----
 

[[File:Approach.png]]

===Expected Results===
----
* '''Issue 1''' - Once this issue is fixed, the Due Dates tab while editing an assignment will have no ambiguity between "late policy" and "penalty policy", as "late policy" will be used exclusively.
* '''Issue 2''' - Once this issue is fixed, late policies can be created without raising the "The following error occurred while saving the penalty policy:" error.
* '''Issue 3''' - Once this issue is fixed, the back link after creating a late policy will rightly take the user to the Edit Assignment page.
* '''Issue 4''' - Once this issue is fixed, "+" and "-" buttons for Show/Hide Date Updater will work and update the dates as it is supposed to.
* '''Issue 5''' - The code coverage will definitely increase once tests for late_policy.rb and late_policies_controller.rb are written.
 

===Test Plan===
----
'''Automated Testing Using RSpec'''

We plan to create two new files, late_policy_spec.rb and late_policies_controller_spec.rb to write tests for late_policy.rb and late_policies_controller.rb repesctively.

'''Coverage'''

To make sure we are covering all of our code (100%) with test cases we will use the Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually running the test file, the SimpleCov gem will highlight the lines of code which are being covered by our test cases in green color, and for those which are not being covered in red.

 

===Milestones===
----
'''11/01''' – Project Selection

'''11/11''' – Create Design Doc

'''11/15''' – setting up project environment and updating Design Doc

'''11/25''' – Fix Issues 1,2 and 3 with well-defined test cases

'''11/30''' – Fix issues 4 and 5 with well-defined test cases

'''12/04''' – Update design doc and create & upload video

'''12/06''' – Write tests for edge cases.

 

===Project Mentors===
----
* Edward Gehringer (efg@ncsu.edu)

* Ramya Vijayakumar (rvijaya4@ncsu.edu)

 

===Team Members===
----
* Rajit Bharambe (rbharam@ncsu.edu)

* Saahil Chawande (schawan@ncsu.edu)

* Natansh Negi (nnegi2@ncsu.edu)

* Hitarth Shah (hshah4@ncsu.edu)

===References===
----
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/rajitnb/expertiza GitHub Project Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]

CSC/ECE 517 Fall 2019 - E1978. Fix issues related to deadlines and late policies

2019-11-11T03:21:52Z

Nnegi2: /* Approach */

==Fix issues related to deadlines and late policies==

This page gives a description of the issues and the approach towards solving them in the E1978. Fix issues related to deadlines and late policies project.

__TOC__

===Problem Description===
----
Expertiza can automatically deduct points if a student is late in performing some action (e.g., submitting or reviewing). This is implemented by defining a new “late policy” and applying it to the assignment. Late policies are managed on the Due dates tab of assignment creation (or editing).

 
====Issues with the Current Implementation====
----
The current implementation of Expertiza has the following Issues:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”. To avoid confusion, use “late policy” exclusively.
* '''Issue 2''' - Late policies cannot be created without raising an error.
* '''Issue 3''' - After creating a late policy, the “back” link does not take the user back to editing the assignment.
* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work. Expertiza has a way of adjusting due dates for a new assignment. If a new assignment is created by copying an old assignment, the due dates are copied too. It is likely that sometimes the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.) is wished. To avoid the need to edit all the deadlines manually, Expertiza has a date updater. However, it does not work.
* '''Issue 5''' - Neither late_policy.rb nor late_policies_controller.rb have any tests at all.

[[File:Upload.png]]

 

===Project Scope===
----

Issues described in the above section all exist in the Due Dates tab on the Edit Assignment page.
* '''Issue 1''' - The scope of this issue is to change "penalty policy" to "late policy" on all the relevant UI screens (app/views/late_policies).
* '''Issue 2''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 3''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 4''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 5''' - The scope of this issue is to write test cases for late_policies_controller.rb and late_policy.rb.

===Approach===
----
 

[[File:Approach.jpg]]

===Expected Results===
----
* '''Issue 1''' - Once this issue is fixed, the Due Dates tab while editing an assignment will have no ambiguity between "late policy" and "penalty policy", as "late policy" will be used exclusively.
* '''Issue 2''' - Once this issue is fixed, late policies can be created without raising the "The following error occurred while saving the penalty policy:" error.
* '''Issue 3''' - Once this issue is fixed, the back link after creating a late policy will rightly take the user to the Edit Assignment page.
* '''Issue 4''' - Once this issue is fixed, "+" and "-" buttons for Show/Hide Date Updater will work and update the dates as it is supposed to.
* '''Issue 5''' - The code coverage will definitely increase once tests for late_policy.rb and late_policies_controller.rb are written.
 

===Test Plan===
----
'''Automated Testing Using RSpec'''

We plan to create two new files, late_policy_spec.rb and late_policies_controller_spec.rb to write tests for late_policy.rb and late_policies_controller.rb repesctively.

'''Coverage'''

To make sure we are covering all of our code (100%) with test cases we will use the Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually running the test file, the SimpleCov gem will highlight the lines of code which are being covered by our test cases in green color, and for those which are not being covered in red.

 

===Milestones===
----
'''11/01''' – Project Selection

'''11/11''' – Create Design Doc

'''11/15''' – setting up project environment and updating Design Doc

'''11/25''' – Fix Issues 1,2 and 3 with well-defined test cases

'''11/30''' – Fix issues 4 and 5 with well-defined test cases

'''12/04''' – Update design doc and create & upload video

'''12/06''' – Write tests for edge cases.

 

===Project Mentors===
----
* Edward Gehringer (efg@ncsu.edu)

* Ramya Vijayakumar (rvijaya4@ncsu.edu)

 

===Team Members===
----
* Rajit Bharambe (rbharam@ncsu.edu)

* Saahil Chawande (schawan@ncsu.edu)

* Natansh Negi (nnegi2@ncsu.edu)

* Hitarth Shah (hshah4@ncsu.edu)

===References===
----
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/rajitnb/expertiza GitHub Project Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]

File:Approach.PNG

2019-11-11T03:21:13Z

Nnegi2:

CSC/ECE 517 Fall 2019 - E1978. Fix issues related to deadlines and late policies

2019-11-11T03:01:34Z

Nnegi2: /* Scope of the Project */

==Fix issues related to deadlines and late policies==

This page gives a description of the issues and the approach towards solving them in the E1978. Fix issues related to deadlines and late policies project.

__TOC__

===Problem Description===
----
Expertiza can automatically deduct points if a student is late in performing some action (e.g., submitting or reviewing). This is implemented by defining a new “late policy” and applying it to the assignment. Late policies are managed on the Due dates tab of assignment creation (or editing).

 
====Issues with the Current Implementation====
----
The current implementation of Expertiza has the following Issues:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”. To avoid confusion, use “late policy” exclusively.
* '''Issue 2''' - Late policies cannot be created without raising an error.
* '''Issue 3''' - After creating a late policy, the “back” link does not take the user back to editing the assignment.
* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work. Expertiza has a way of adjusting due dates for a new assignment. If a new assignment is created by copying an old assignment, the due dates are copied too. It is likely that sometimes the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.) is wished. To avoid the need to edit all the deadlines manually, Expertiza has a date updater. However, it does not work.
* '''Issue 5''' - Neither late_policy.rb nor late_policies_controller.rb have any tests at all.

[[File:Upload.png]]

 

===Project Scope===
----

Issues described in the above section all exist in the Due Dates tab on the Edit Assignment page.
* '''Issue 1''' - The scope of this issue is to change "penalty policy" to "late policy" on all the relevant UI screens (app/views/late_policies).
* '''Issue 2''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 3''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 4''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 5''' - The scope of this issue is to write test cases for late_policies_controller.rb and late_policy.rb.

Issues described in the above section all exist in the Due Dates tab on the Edit Assignment page.
* '''Issue 1''' - Once this issue is fixed, the Due Dates tab while editing an assignment will have no ambiguity between "late policy" and "penalty policy", as "late policy" will be used exclusively.
* '''Issue 2''' - Once this issue is fixed, late policies can be created without raising the "The following error occurred while saving the penalty policy:" error.
* '''Issue 3''' - Once this issue is fixed, the back link after creating a late policy will rightly take the user to the Edit Assignment page.
* '''Issue 4''' - Once this issue is fixed, "+" and "-" buttons for Show/Hide Date Updater will work and update the dates as it is supposed to.
* '''Issue 5''' - The code coverage will definitely increase once tests for late_policy.rb and late_policies_controller.rb are written.
 

===Approach===
----
 

===Test Plan===
----

'''Automated Testing Using RSpec'''

We plan to create two new files, late_policy_spec.rb and late_policies_controller_spec.rb to write tests for late_policy.rb and late_policies_controller.rb repesctively.

'''Coverage'''

To make sure we are covering all of our code (100%) with test cases we will use the Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually running the test file, the SimpleCov gem will highlight the lines of code which are being covered by our test cases in green color, and for those which are not being covered in red.
 

===Milestones===
----
'''11/01''' – Project Selection

'''11/11''' – Create Design Doc

'''11/15''' – setting up project environment and updating Design Doc

'''11/25''' – Fix Issues 1,2 and 3 with well-defined test cases

'''11/30''' – Fix issues 4 and 5 with well-defined test cases

'''12/04''' – Update design doc and create & upload video

'''12/06''' – Write tests for edge cases.

 

===Project Mentors===
----
1. Edward Gehringer (efg@ncsu.edu)

2. Ramya Vijayakumar (rvijaya4@ncsu.edu)

===Team Members===
----
1. Rajit Bharambe (rbharam@ncsu.edu)

2. Saahil Chawande (schawan@ncsu.edu)

3. Natansh Negi (nnegi2@ncsu.edu)

4. Hitarth Shah (hshah4@ncsu.edu)

CSC/ECE 517 Fall 2019 - E1978. Fix issues related to deadlines and late policies

2019-11-11T03:01:12Z

Nnegi2: /* Scope of the Project */

==Fix issues related to deadlines and late policies==

This page gives a description of the issues and the approach towards solving them in the E1978. Fix issues related to deadlines and late policies project.

__TOC__

===Problem Description===
----
Expertiza can automatically deduct points if a student is late in performing some action (e.g., submitting or reviewing). This is implemented by defining a new “late policy” and applying it to the assignment. Late policies are managed on the Due dates tab of assignment creation (or editing).

 
====Issues with the Current Implementation====
----
The current implementation of Expertiza has the following Issues:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”. To avoid confusion, use “late policy” exclusively.
* '''Issue 2''' - Late policies cannot be created without raising an error.
* '''Issue 3''' - After creating a late policy, the “back” link does not take the user back to editing the assignment.
* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work. Expertiza has a way of adjusting due dates for a new assignment. If a new assignment is created by copying an old assignment, the due dates are copied too. It is likely that sometimes the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.) is wished. To avoid the need to edit all the deadlines manually, Expertiza has a date updater. However, it does not work.
* '''Issue 5''' - Neither late_policy.rb nor late_policies_controller.rb have any tests at all.

[[File:Upload.png]]

 

===Scope of the Project===
----

Issues described in the above section all exist in the Due Dates tab on the Edit Assignment page.
* '''Issue 1''' - The scope of this issue is to change "penalty policy" to "late policy" on all the relevant UI screens (app/views/late_policies).
* '''Issue 2''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 3''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 4''' - The scope of this issue is to fix the function in ruby and write appropriate test cases (late_policies_controller.rb).
* '''Issue 5''' - The scope of this issue is to write test cases for late_policies_controller.rb and late_policy.rb.

Issues described in the above section all exist in the Due Dates tab on the Edit Assignment page.
* '''Issue 1''' - Once this issue is fixed, the Due Dates tab while editing an assignment will have no ambiguity between "late policy" and "penalty policy", as "late policy" will be used exclusively.
* '''Issue 2''' - Once this issue is fixed, late policies can be created without raising the "The following error occurred while saving the penalty policy:" error.
* '''Issue 3''' - Once this issue is fixed, the back link after creating a late policy will rightly take the user to the Edit Assignment page.
* '''Issue 4''' - Once this issue is fixed, "+" and "-" buttons for Show/Hide Date Updater will work and update the dates as it is supposed to.
* '''Issue 5''' - The code coverage will definitely increase once tests for late_policy.rb and late_policies_controller.rb are written.
 

===Approach===
----
 

===Test Plan===
----

'''Automated Testing Using RSpec'''

We plan to create two new files, late_policy_spec.rb and late_policies_controller_spec.rb to write tests for late_policy.rb and late_policies_controller.rb repesctively.

'''Coverage'''

To make sure we are covering all of our code (100%) with test cases we will use the Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually running the test file, the SimpleCov gem will highlight the lines of code which are being covered by our test cases in green color, and for those which are not being covered in red.
 

===Milestones===
----
'''11/01''' – Project Selection

'''11/11''' – Create Design Doc

'''11/15''' – setting up project environment and updating Design Doc

'''11/25''' – Fix Issues 1,2 and 3 with well-defined test cases

'''11/30''' – Fix issues 4 and 5 with well-defined test cases

'''12/04''' – Update design doc and create & upload video

'''12/06''' – Write tests for edge cases.

 

===Project Mentors===
----
1. Edward Gehringer (efg@ncsu.edu)
2. Ramya Vijayakumar (rvijaya4@ncsu.edu)

===Team Members===
----
1. Rajit Bharambe (rbharam@ncsu.edu)
2. Saahil Chawande (schawan@ncsu.edu)
3. Natansh Negi (nnegi2@ncsu.edu)
4. Hitarth Shah (hshah4@ncsu.edu)

CSC/ECE 517 Fall 2019 - E1978. Fix issues related to deadlines and late policies

2019-11-11T02:51:14Z

Nnegi2: /* Test Plan */

==Fix issues related to deadlines and late policies==

This page gives a description of the issues and the approach towards solving them in the E1978. Fix issues related to deadlines and late policies project.

__TOC__

===Problem Description===
----
Expertiza can automatically deduct points if a student is late in performing some action (e.g., submitting or reviewing). This is implemented by defining a new “late policy” and applying it to the assignment. Late policies are managed on the Due dates tab of assignment creation (or editing).

 
====Issues with the Current Implementation====
----
The current implementation of Expertiza has the following Issues:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”. To avoid confusion, use “late policy” exclusively.
* '''Issue 2''' - Late policies cannot be created without raising an error.
* '''Issue 3''' - After creating a late policy, the “back” link does not take the user back to editing the assignment.
* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work. Expertiza has a way of adjusting due dates for a new assignment. If a new assignment is created by copying an old assignment, the due dates are copied too. It is likely that sometimes the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.) is wished. To avoid the need to edit all the deadlines manually, Expertiza has a date updater. However, it does not work.
* '''Issue 5''' - Neither late_policy.rb nor late_policies_controller.rb have any tests at all.

[[File:Upload.png]]

 

===Scope of the Project===
----

Issues described in the above section all exist in the Due Dates tab on the Edit Assignment page.
* '''Issue 1''' - Once this issue is fixed, the Due Dates tab while editing an assignment will have no ambiguity between "late policy" and "penalty policy", as "late policy" will be used exclusively.
* '''Issue 2''' - Once this issue is fixed, late policies can be created without raising the "The following error occurred while saving the penalty policy:" error.
* '''Issue 3''' - Once this issue is fixed, the back link after creating a late policy will rightly take the user to the Edit Assignment page.
* '''Issue 4''' - Once this issue is fixed, "+" and "-" buttons for Show/Hide Date Updater will work and update the dates as it is supposed to.
* '''Issue 5''' - The code coverage will definitely increase once tests for late_policy.rb and late_policies_controller.rb are written.
 

===Approach===
----
 

===Test Plan===
----

'''Automated Testing Using Rspec'''
 
We plan to create two new files, late_policy_spec.rb and late_policies_controller_spec.rb to test late_policy.rb and late_policies_controller.rb repesctively.

'''Coverage'''

To make sure we are covering all of our code (100%) with test cases we will use the Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually running the test file, the SimpleCov gem will highlight the lines of code which are being covered by our test cases in green color, and for those which are not being covered in red.
----
 

===Milestones===
----
'''11/01''' – Project Selection

'''11/11''' – Create Design Doc

'''11/15''' – setting up project environment and updating Design Doc

'''11/25''' – Fix Issues 1,2 and 3 with well-defined test cases

'''11/30''' – Fix issues 4 and 5 with well-defined test cases

'''12/04''' – Update design doc and create & upload video

'''12/06''' – Write tests for edge cases.

CSC/ECE 517 Fall 2019 - E1978. Fix issues related to deadlines and late policies

2019-11-11T02:50:18Z

Nnegi2: /* Fix issues related to deadlines and late policies */

==Fix issues related to deadlines and late policies==

This page gives a description of the issues and the approach towards solving them in the E1978. Fix issues related to deadlines and late policies project.

__TOC__

===Problem Description===
----
Expertiza can automatically deduct points if a student is late in performing some action (e.g., submitting or reviewing). This is implemented by defining a new “late policy” and applying it to the assignment. Late policies are managed on the Due dates tab of assignment creation (or editing).

 
====Issues with the Current Implementation====
----
The current implementation of Expertiza has the following Issues:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”. To avoid confusion, use “late policy” exclusively.
* '''Issue 2''' - Late policies cannot be created without raising an error.
* '''Issue 3''' - After creating a late policy, the “back” link does not take the user back to editing the assignment.
* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work. Expertiza has a way of adjusting due dates for a new assignment. If a new assignment is created by copying an old assignment, the due dates are copied too. It is likely that sometimes the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.) is wished. To avoid the need to edit all the deadlines manually, Expertiza has a date updater. However, it does not work.
* '''Issue 5''' - Neither late_policy.rb nor late_policies_controller.rb have any tests at all.

 

===Scope of the Project===
----

Issues described in the above section all exist in the Due Dates tab on the Edit Assignment page.
* '''Issue 1''' - Once this issue is fixed, the Due Dates tab while editing an assignment will have no ambiguity between "late policy" and "penalty policy", as "late policy" will be used exclusively.
* '''Issue 2''' - Once this issue is fixed, late policies can be created without raising the "The following error occurred while saving the penalty policy:" error.
* '''Issue 3''' - Once this issue is fixed, the back link after creating a late policy will rightly take the user to the Edit Assignment page.
* '''Issue 4''' - Once this issue is fixed, "+" and "-" buttons for Show/Hide Date Updater will work and update the dates as it is supposed to.
* '''Issue 5''' - The code coverage will definitely increase once tests for late_policy.rb and late_policies_controller.rb are written.
 

===Approach===
----
 

===Test Plan===
----

'''Automated Testing Using Rspec'''
 
We plan to create two new files, late_policy_spec.rb and late_policies_controller_spec.rb to test late_policy.rb and late_policies_controller.rb repesctively.

'''Coverage'''

To make sure we are covering all of our code (100%) with test cases we will use Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually runnung the test file, the SimpleCov gem will highlight the lines of code which are being covered by our test cases in green color, and for those which are not being covered in red.
----
 

===Milestones===
----
'''11/01''' – Project Selection

'''11/11''' – Create Design Doc

'''11/15''' – setting up project environment and updating Design Doc

'''11/25''' – Fix Issues 1,2 and 3 with well-defined test cases

'''11/30''' – Fix issues 4 and 5 with well-defined test cases

'''12/04''' – Update design doc and create & upload video

'''12/06''' – Write tests for edge cases.

CSC/ECE 517 Fall 2019 - E1978. Fix issues related to deadlines and late policies

2019-11-11T02:48:10Z

Nnegi2:

==Fix issues related to deadlines and late policies==

This page gives a description of the issues and the approach towards solving them in the E1978. Fix issues related to deadlines and late policies project.

__TOC__

===Problem Description===
----
Expertiza can automatically deduct points if a student is late in performing some action (e.g., submitting or reviewing). This is implemented by defining a new “late policy” and applying it to the assignment. Late policies are managed on the Due dates tab of assignment creation (or editing).

 
====Issues with the Current Implementation====
----
The current implementation of Expertiza has the following Issues:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”. To avoid confusion, use “late policy” exclusively.
* '''Issue 2''' - Late policies cannot be created without raising an error.
* '''Issue 3''' - After creating a late policy, the “back” link does not take the user back to editing the assignment.
* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work. Expertiza has a way of adjusting due dates for a new assignment. If a new assignment is created by copying an old assignment, the due dates are copied too. It is likely that sometimes the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.) is wished. To avoid the need to edit all the deadlines manually, Expertiza has a date updater. However, it does not work.
* '''Issue 5''' - Neither late_policy.rb nor late_policies_controller.rb have any tests at all.

 

===Scope of the Project===
----
 
Issues described in the above section all exist in the Due Dates tab on the Edit Assignment page.
* '''Issue 1''' - Once this issue is fixed, the Due Dates tab while editing an assignment will have no ambiguity between "late policy" and "penalty policy", as "late policy" will be used exclusively.
* '''Issue 2''' - Once this issue is fixed, late policies can be created without raising the "The following error occurred while saving the penalty policy:" error.
* '''Issue 3''' - Once this issue is fixed, the back link after creating a late policy will rightly take the user to the Edit Assignment page.
* '''Issue 4''' - Once this issue is fixed, "+" and "-" buttons for Show/Hide Date Updater will work and update the dates as it is supposed to.
* '''Issue 5''' - The code coverage will definitely increase once tests for late_policy.rb and late_policies_controller.rb are written.
 

===Approach===
----
 

===Test Plan===
----
 
'''Automated Testing Using Rspec'''
 
We plan to create two new files, late_policy_spec.rb and late_policies_controller_spec.rb to test late_policy.rb and late_policies_controller.rb repesctively.

'''Coverage'''
 
To make sure we are covering all of our code (100%) with test cases we will use Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually runnung the test file, the SimpleCov gem will highlight the lines of code which are being covered by our test cases in green color, and for those which are not being covered in red.
----
 

===Milestones===
----
 
'''11/01''' – Project Selection

'''11/11''' – Create Design Doc

'''11/15''' – setting up project environment and updating Design Doc

'''11/25''' – Fix Issues 1,2 and 3 with well-defined test cases

'''11/30''' – Fix issues 4 and 5 with well-defined test cases

'''12/04''' – Update design doc and create & upload video

'''12/06''' – Write tests for edge cases.

CSC/ECE 517 Fall 2019 - E1963. Changing assignment participant role

2019-11-07T01:12:52Z

Nnegi2: /* Test Plan */

= E1963 Changing assignment Participant role=

===Background===

* E1963 This project aims to enable the instructor to change the role of an assignment participant. There are two ways to add a new assignment participant, first being through the Add button on the assignment participant page. Another way is to import via a spreadsheet with the list of users that are to be added. The motivation of E1963 was to enable the instructors adding these users using either of the methods mentioned above to change these users' role. A user can have one of the following roles - participant, reader, reviewer, submitter.

* The existing UI had the a dropdown that displayed the role of the user, we have added a Submit button below each dropdown to enable the instructor to change the role of the user. On clicking the submit button, the role associated with that user is changed in the persistent storage. We have also added a flash message which confirms the change to the user.

The following issues were targeted in this project:
* '''#1:''' The instructor does not have the option to change the role of the user, once he/she has been added to the assignment. Thus, if the instructor wishes to change the role of a user from say a reviewer to a submitter, he/she is not able to save the changes.
* '''#2:''' With the changes made for the issue mentioned above, the instructor will be able to save the changes manually. We would like to maintain the same behavior when the assignment participants are imported from excel. Upon creating a new user using an Excel import, the user should have the role of a participant by default. An instructor was then unable to change the role of the assignment participant.

===Navigation===
Manage Assignments -> Add new participant icon under Actions

===Current implementation===
For each of the assignment participant record, there is a dropdown which contains the role of the participant. When the instructor attempts to change the value in the dropdown, it is not reflected in the backend, as there is no call associated with it, to submit the changes. Thus when the user revisits the page, the changes would he would have made are not retained.

Authorization of the user is based on the flags can_submit, can_review and can_take_quiz flags, which are set to be true or false based on the role of the user. By default, the user is assigned the role of a participant in any assignment. Thus, the goal is to modify these flags and save them in the database when the role of the assignment participant is changed, so that it is a persistent change.
Authorization of the users based on the flags can be deduced as follows:
* Participant has can_submit=true, can_review=true and can_take_quiz=true
* Reader has can_submit= false, can_review=true and can_take_quiz= true
* Submitter has can_submit=true, can_review= false and can_take_quiz=false
* Reviewer has can_submit=false, can_review= true and can_take_quiz=false

Problems:
* 1. There is no way to change the role of the user, once the user has been added to the assignment as a participant. (Submit button now resolves this issue.)
* 2. Instructor is not given any confirmation that the role of the participant has been reverted to the original value once he/she navigates somewhere else. This is misleading for an instructor as the he/she might be under the impression that the changes he/she made have been saved. (Flash message now lets the user know about the change.)

===Snapshots depicting the issue===

* As an Instructor, go to Manage Assignments
 
[[File:Screenshot ManageAssignments.png]]
 

* Click on add participant
 
[[File:Screenshot AssignmentParticipants copy.png]]
 

* Note that the user on the first record is currently a "Reader"
 
[[File:Screenshot Currently Reader.png]]
 

* Change the role of the "Reader" to say "Submitter"
 
[[File:Screenshot Submitter.png]]
 

* Refresh or re-navigate to this page and note that the changes are reverted
 
[[File:Screenshot back to Reader.png]]
 

===Implementation===

Changes are made in the partial for participants "_participant.rb", so that the submit button is rendered on the view.
Upon changing the selected value for the user role, 'update_authorizations' method is called from participants controller which passes the participant id as a parameter to the method to change it's role in the database. The selected role is passed as a parameter 'authorization' to the update authorization method that updates the can_submit, can_take_quiz, and can_review flags appropriately for each role as described above for the selected participant id.

Implementing the above mentioned changes, allows the instructor to change the value of role in the dropdown which retains the corresponding record on tap of the Submit button. We have verified that the changes in the above mentioned flags are reflected in the database. The instructor will be presented with a success message on changing the role of the selected participant, on clicking submit. The instructor can revisit the page and expect the updated value to be retained. Both the problems listed above are taken care of such as the instructor is facilitated with an option to change the participant, as well as knows that the change made will be durable.

===Snapshots after the changes===

* Submit button has been added to each row of assignment participants
 
[[File:Screenshot Submit Added 1.png]]
 
* Change the "Reader" to "Submitter", on the first record and click on submit. Changes have been persisted. Flash message confirmation is also provided to the Instructor to let him/her know of the change.
 
[[File:Screenshot submitter saved 2.png]]
 

===Additional Changes===
(These changes were not part of the assigned issue E1963, these are additional issues that we encountered while fixing E1963)

In addition to the above-mentioned issue, we fixed a few other issues that we observed , which were relevant to Assignment Participant and Course Participant Controllers, namely:

'''1. Export Details''' in Assignment Participants view: We noticed that a a blank csv file was getting generated on exporting detail button in Manage Assignments. We discovered that the reason for this issue is that in the import method, the model defined was that of AssignmentParticipant whereas all the parsing methods for export were present in Assignment model. We did the required changes, tested the functionality and note that this is working fine now.
The changes for this are made in the common module - export_file_controller.rb following which the export and export_details methods are now called from the assignment.rb as opposed to assignment_participant.rb where there are no export methods and their corresponding implementations.
Now, the Export Detail button generates a comma-seperated file with the following headers:
* Assignment Name
* Assignment Instructor
* Team ID / Author ID
* Reviewee (Team / Student Name)
* Reviewer
* Question / Criterion
* Question ID
* Answer / Comment ID
* Answer / Comment
* Score

'''2. ''' Along with the previous issue, we found that since the partials were shared among Assignment Participant and Course Participant, Course Participant also had the Export Details section and the corresponding button. However, it is not required and we believe that it should be removed from the view. We consulted Dr. Gehringer and based on his feedback as well, we removed the semi-view consisting of "Export Details" from Course Participant. The changes are made in the file "start.html.erb" by using conditional rendering of the partial based on the model name.

'''The view before change:'''

 
[[File:Screen Shot Before Remove Export Detauls.png]]
 

'''The view after change:'''

 
[[File:Screen Shot After Remove Export Details.png]]
 

'''3. Missing Handle: Assignment Participant''' on adding a new Assignment Participant: We observed that when a new assignment participant is created, if a user already exists with the username, the existing user is added to that Assignment and his existing handle attribute in Users table is mapped to the handle attribute in Participants table. However, if a new user is added not currently in the Users table, a new entry is created first in the Users table and is then replicated in the Participants table. Although, we noticed that the handle attribute in Participants table was coming as null. We fixed this issue by making change in the define_attributes method in ImportFileHelper.rb.

'''4. Import Assignment Participants''' was not working - It is expected that if a user does not exist in the system, on importing assignment participants, a user will be created and he/she will be added to the assignment as a participant. With the current implementation, the user was getting created, however corresponding AssignmentParticipant was not getting created due to a validation with respect to handle. We have fixed this issue by setting the handle in AssignmentParticipants to be the same as the name of the user created (in accordance with the current functionality - when a user is added as an AssignmentParticipant from the UI). This facilitates us to import AssignmentParticipants.
The mandatory minimal attributes required to import an assignment participant are :
* Username
* Full name
* Email id
* Password.

'''5. The role in the Assignment Participant view''' doesn't have a header unlike all the other attributes on the view. We added a header for the role, thereby increasing the readability and consistency on the UI. The required changes are made in the partial "_user_list.html"

'''The view before change:'''

 
[[File:Screen Shot Before Participant AP.png]]
 

'''The view after change:'''

 
[[File:Screen Shot After Participant AP.png]]
 

'''6. The role in the Course Participant view''' doesn't have a header unlike all the other attributes on the view. We added a header for the role, thereby increasing the readability and consistency on the UI. The required changes are made in the partial "_user_list.html"

'''The view before change:'''

 
[[File:Screen Shot Before Participant CP.png]]
 

'''The view after change:'''

 
[[File:Screen Shot After Participant Role CP.png]]
 

===Test Plan===
Rspec test has been added to check the update authorizations functionality in the participants_controller_spec.rb. The test verifies the change of flags mentioned above as per the authorization of the user. The tests also checks whether the expected flash message is visible on the UI. Code coverage is '''100%''' for all the code that we have added in the controllers, as part of this project.

To make sure we covered all of our code (100%) with test cases we used Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually running the test file, the SimpleCov gem highlights the lines of code which are covered by our test cases with green color, and with red color for lines for which are not covered by our test cases. The image below shows the output of SimpleCov gem for the file participants_controller_spec.rb with 100% code coverage (all green).

'''Please see the coverage of the code as shown in the screenshot below:'''

 
[[File:Screen Shot code coverage.png]]
 

'''Please find the tests added below:'''
<pre>
describe '#validate_authorizations' do
#Test case for successful update of participant to reviewer, expects the success flash message
it 'updates the authorizations for the participant to make them reviewer' do
allow(Participant).to receive(:find).with('1').and_return(participant)
params = {authorization: 'reviewer', id: 1}
session = {user: instructor}
get :update_authorizations, params, session
expect(flash[:success]).to eq 'The role of the selected participants has been successfully updated.'
expect(participant.can_review).to eq(true)
expect(participant.can_submit).to eq(false)
expect(participant.can_take_quiz).to eq(false)
end

#Test for case where we expect to encounter an error in update_attributes method
it ' throws an exception while validating authorizations' do
allow(Participant).to receive(:find).with('1').and_return(participant)
allow(participant).to receive(:update_attributes).and_raise(StandardError)
params = {authorization: 'reviewer', id: 1}
session = {user: instructor}
get :update_authorizations, params, session
expect(flash[:error]).to eq 'The update action failed.'
end

end
</pre>

===Team===
#Natansh Negi (nnegi2@ncsu.edu)
#Richa Dua (rdua2@ncsu.edu)
#Roshani Narasimhan (rnarasi2@ncsu.edu)
'''Mentor:''' Sharique Khan (mkhan8@ncsu.edu)

===References===
* [https://github.com/expertiza/expertiza Link to expertiza]
* [https://github.com/RoshaniN/expertiza-team-622.git Link to changes E1963]
* [https://github.com/expertiza/expertiza/pull/1533 Link to Pull request]
* [http://152.46.19.56:8080/ Link to deployed application on VCL]

CSC/ECE 517 Fall 2019 - E1963. Changing assignment participant role

2019-11-07T01:12:18Z

Nnegi2: /* Test Plan */

= E1963 Changing assignment Participant role=

===Background===

* E1963 This project aims to enable the instructor to change the role of an assignment participant. There are two ways to add a new assignment participant, first being through the Add button on the assignment participant page. Another way is to import via a spreadsheet with the list of users that are to be added. The motivation of E1963 was to enable the instructors adding these users using either of the methods mentioned above to change these users' role. A user can have one of the following roles - participant, reader, reviewer, submitter.

* The existing UI had the a dropdown that displayed the role of the user, we have added a Submit button below each dropdown to enable the instructor to change the role of the user. On clicking the submit button, the role associated with that user is changed in the persistent storage. We have also added a flash message which confirms the change to the user.

The following issues were targeted in this project:
* '''#1:''' The instructor does not have the option to change the role of the user, once he/she has been added to the assignment. Thus, if the instructor wishes to change the role of a user from say a reviewer to a submitter, he/she is not able to save the changes.
* '''#2:''' With the changes made for the issue mentioned above, the instructor will be able to save the changes manually. We would like to maintain the same behavior when the assignment participants are imported from excel. Upon creating a new user using an Excel import, the user should have the role of a participant by default. An instructor was then unable to change the role of the assignment participant.

===Navigation===
Manage Assignments -> Add new participant icon under Actions

===Current implementation===
For each of the assignment participant record, there is a dropdown which contains the role of the participant. When the instructor attempts to change the value in the dropdown, it is not reflected in the backend, as there is no call associated with it, to submit the changes. Thus when the user revisits the page, the changes would he would have made are not retained.

Authorization of the user is based on the flags can_submit, can_review and can_take_quiz flags, which are set to be true or false based on the role of the user. By default, the user is assigned the role of a participant in any assignment. Thus, the goal is to modify these flags and save them in the database when the role of the assignment participant is changed, so that it is a persistent change.
Authorization of the users based on the flags can be deduced as follows:
* Participant has can_submit=true, can_review=true and can_take_quiz=true
* Reader has can_submit= false, can_review=true and can_take_quiz= true
* Submitter has can_submit=true, can_review= false and can_take_quiz=false
* Reviewer has can_submit=false, can_review= true and can_take_quiz=false

Problems:
* 1. There is no way to change the role of the user, once the user has been added to the assignment as a participant. (Submit button now resolves this issue.)
* 2. Instructor is not given any confirmation that the role of the participant has been reverted to the original value once he/she navigates somewhere else. This is misleading for an instructor as the he/she might be under the impression that the changes he/she made have been saved. (Flash message now lets the user know about the change.)

===Snapshots depicting the issue===

* As an Instructor, go to Manage Assignments
 
[[File:Screenshot ManageAssignments.png]]
 

* Click on add participant
 
[[File:Screenshot AssignmentParticipants copy.png]]
 

* Note that the user on the first record is currently a "Reader"
 
[[File:Screenshot Currently Reader.png]]
 

* Change the role of the "Reader" to say "Submitter"
 
[[File:Screenshot Submitter.png]]
 

* Refresh or re-navigate to this page and note that the changes are reverted
 
[[File:Screenshot back to Reader.png]]
 

===Implementation===

Changes are made in the partial for participants "_participant.rb", so that the submit button is rendered on the view.
Upon changing the selected value for the user role, 'update_authorizations' method is called from participants controller which passes the participant id as a parameter to the method to change it's role in the database. The selected role is passed as a parameter 'authorization' to the update authorization method that updates the can_submit, can_take_quiz, and can_review flags appropriately for each role as described above for the selected participant id.

Implementing the above mentioned changes, allows the instructor to change the value of role in the dropdown which retains the corresponding record on tap of the Submit button. We have verified that the changes in the above mentioned flags are reflected in the database. The instructor will be presented with a success message on changing the role of the selected participant, on clicking submit. The instructor can revisit the page and expect the updated value to be retained. Both the problems listed above are taken care of such as the instructor is facilitated with an option to change the participant, as well as knows that the change made will be durable.

===Snapshots after the changes===

* Submit button has been added to each row of assignment participants
 
[[File:Screenshot Submit Added 1.png]]
 
* Change the "Reader" to "Submitter", on the first record and click on submit. Changes have been persisted. Flash message confirmation is also provided to the Instructor to let him/her know of the change.
 
[[File:Screenshot submitter saved 2.png]]
 

===Additional Changes===
(These changes were not part of the assigned issue E1963, these are additional issues that we encountered while fixing E1963)

In addition to the above-mentioned issue, we fixed a few other issues that we observed , which were relevant to Assignment Participant and Course Participant Controllers, namely:

'''1. Export Details''' in Assignment Participants view: We noticed that a a blank csv file was getting generated on exporting detail button in Manage Assignments. We discovered that the reason for this issue is that in the import method, the model defined was that of AssignmentParticipant whereas all the parsing methods for export were present in Assignment model. We did the required changes, tested the functionality and note that this is working fine now.
The changes for this are made in the common module - export_file_controller.rb following which the export and export_details methods are now called from the assignment.rb as opposed to assignment_participant.rb where there are no export methods and their corresponding implementations.
Now, the Export Detail button generates a comma-seperated file with the following headers:
* Assignment Name
* Assignment Instructor
* Team ID / Author ID
* Reviewee (Team / Student Name)
* Reviewer
* Question / Criterion
* Question ID
* Answer / Comment ID
* Answer / Comment
* Score

'''2. ''' Along with the previous issue, we found that since the partials were shared among Assignment Participant and Course Participant, Course Participant also had the Export Details section and the corresponding button. However, it is not required and we believe that it should be removed from the view. We consulted Dr. Gehringer and based on his feedback as well, we removed the semi-view consisting of "Export Details" from Course Participant. The changes are made in the file "start.html.erb" by using conditional rendering of the partial based on the model name.

'''The view before change:'''

 
[[File:Screen Shot Before Remove Export Detauls.png]]
 

'''The view after change:'''

 
[[File:Screen Shot After Remove Export Details.png]]
 

'''3. Missing Handle: Assignment Participant''' on adding a new Assignment Participant: We observed that when a new assignment participant is created, if a user already exists with the username, the existing user is added to that Assignment and his existing handle attribute in Users table is mapped to the handle attribute in Participants table. However, if a new user is added not currently in the Users table, a new entry is created first in the Users table and is then replicated in the Participants table. Although, we noticed that the handle attribute in Participants table was coming as null. We fixed this issue by making change in the define_attributes method in ImportFileHelper.rb.

'''4. Import Assignment Participants''' was not working - It is expected that if a user does not exist in the system, on importing assignment participants, a user will be created and he/she will be added to the assignment as a participant. With the current implementation, the user was getting created, however corresponding AssignmentParticipant was not getting created due to a validation with respect to handle. We have fixed this issue by setting the handle in AssignmentParticipants to be the same as the name of the user created (in accordance with the current functionality - when a user is added as an AssignmentParticipant from the UI). This facilitates us to import AssignmentParticipants.
The mandatory minimal attributes required to import an assignment participant are :
* Username
* Full name
* Email id
* Password.

'''5. The role in the Assignment Participant view''' doesn't have a header unlike all the other attributes on the view. We added a header for the role, thereby increasing the readability and consistency on the UI. The required changes are made in the partial "_user_list.html"

'''The view before change:'''

 
[[File:Screen Shot Before Participant AP.png]]
 

'''The view after change:'''

 
[[File:Screen Shot After Participant AP.png]]
 

'''6. The role in the Course Participant view''' doesn't have a header unlike all the other attributes on the view. We added a header for the role, thereby increasing the readability and consistency on the UI. The required changes are made in the partial "_user_list.html"

'''The view before change:'''

 
[[File:Screen Shot Before Participant CP.png]]
 

'''The view after change:'''

 
[[File:Screen Shot After Participant Role CP.png]]
 

===Test Plan===
Rspec test has been added to check the update authorizations functionality in the participants_controller_spec.rb. The test verifies the change of flags mentioned above as per the authorization of the user. The tests also checks whether the expected flash message is visible on the UI. Code coverage is '''100%''' for all the code that we have added in the controllers, as part of this project.

To make sure we covered all of our code (100%) with test cases we used Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually running the test file, the SimpleCov gem highlights the lines of code which are covered by our test cases with green color, and with red color for lines for which are not covered by our test cases. The image below shows the output of SimpleCov gem for the file participants_controller_spec.rb.

'''Please see the coverage of the code as shown in the screenshot below:'''

 
[[File:Screen Shot code coverage.png]]
 

'''Please find the tests added below:'''
<pre>
describe '#validate_authorizations' do
#Test case for successful update of participant to reviewer, expects the success flash message
it 'updates the authorizations for the participant to make them reviewer' do
allow(Participant).to receive(:find).with('1').and_return(participant)
params = {authorization: 'reviewer', id: 1}
session = {user: instructor}
get :update_authorizations, params, session
expect(flash[:success]).to eq 'The role of the selected participants has been successfully updated.'
expect(participant.can_review).to eq(true)
expect(participant.can_submit).to eq(false)
expect(participant.can_take_quiz).to eq(false)
end

#Test for case where we expect to encounter an error in update_attributes method
it ' throws an exception while validating authorizations' do
allow(Participant).to receive(:find).with('1').and_return(participant)
allow(participant).to receive(:update_attributes).and_raise(StandardError)
params = {authorization: 'reviewer', id: 1}
session = {user: instructor}
get :update_authorizations, params, session
expect(flash[:error]).to eq 'The update action failed.'
end

end
</pre>

===Team===
#Natansh Negi (nnegi2@ncsu.edu)
#Richa Dua (rdua2@ncsu.edu)
#Roshani Narasimhan (rnarasi2@ncsu.edu)
'''Mentor:''' Sharique Khan (mkhan8@ncsu.edu)

===References===
* [https://github.com/expertiza/expertiza Link to expertiza]
* [https://github.com/RoshaniN/expertiza-team-622.git Link to changes E1963]
* [https://github.com/expertiza/expertiza/pull/1533 Link to Pull request]
* [http://152.46.19.56:8080/ Link to deployed application on VCL]

CSC/ECE 517 Fall 2019 - E1963. Changing assignment participant role

2019-11-07T01:11:32Z

Nnegi2: /* Test Plan */

= E1963 Changing assignment Participant role=

===Background===

* E1963 This project aims to enable the instructor to change the role of an assignment participant. There are two ways to add a new assignment participant, first being through the Add button on the assignment participant page. Another way is to import via a spreadsheet with the list of users that are to be added. The motivation of E1963 was to enable the instructors adding these users using either of the methods mentioned above to change these users' role. A user can have one of the following roles - participant, reader, reviewer, submitter.

* The existing UI had the a dropdown that displayed the role of the user, we have added a Submit button below each dropdown to enable the instructor to change the role of the user. On clicking the submit button, the role associated with that user is changed in the persistent storage. We have also added a flash message which confirms the change to the user.

The following issues were targeted in this project:
* '''#1:''' The instructor does not have the option to change the role of the user, once he/she has been added to the assignment. Thus, if the instructor wishes to change the role of a user from say a reviewer to a submitter, he/she is not able to save the changes.
* '''#2:''' With the changes made for the issue mentioned above, the instructor will be able to save the changes manually. We would like to maintain the same behavior when the assignment participants are imported from excel. Upon creating a new user using an Excel import, the user should have the role of a participant by default. An instructor was then unable to change the role of the assignment participant.

===Navigation===
Manage Assignments -> Add new participant icon under Actions

===Current implementation===
For each of the assignment participant record, there is a dropdown which contains the role of the participant. When the instructor attempts to change the value in the dropdown, it is not reflected in the backend, as there is no call associated with it, to submit the changes. Thus when the user revisits the page, the changes would he would have made are not retained.

Authorization of the user is based on the flags can_submit, can_review and can_take_quiz flags, which are set to be true or false based on the role of the user. By default, the user is assigned the role of a participant in any assignment. Thus, the goal is to modify these flags and save them in the database when the role of the assignment participant is changed, so that it is a persistent change.
Authorization of the users based on the flags can be deduced as follows:
* Participant has can_submit=true, can_review=true and can_take_quiz=true
* Reader has can_submit= false, can_review=true and can_take_quiz= true
* Submitter has can_submit=true, can_review= false and can_take_quiz=false
* Reviewer has can_submit=false, can_review= true and can_take_quiz=false

Problems:
* 1. There is no way to change the role of the user, once the user has been added to the assignment as a participant. (Submit button now resolves this issue.)
* 2. Instructor is not given any confirmation that the role of the participant has been reverted to the original value once he/she navigates somewhere else. This is misleading for an instructor as the he/she might be under the impression that the changes he/she made have been saved. (Flash message now lets the user know about the change.)

===Snapshots depicting the issue===

* As an Instructor, go to Manage Assignments
 
[[File:Screenshot ManageAssignments.png]]
 

* Click on add participant
 
[[File:Screenshot AssignmentParticipants copy.png]]
 

* Note that the user on the first record is currently a "Reader"
 
[[File:Screenshot Currently Reader.png]]
 

* Change the role of the "Reader" to say "Submitter"
 
[[File:Screenshot Submitter.png]]
 

* Refresh or re-navigate to this page and note that the changes are reverted
 
[[File:Screenshot back to Reader.png]]
 

===Implementation===

Changes are made in the partial for participants "_participant.rb", so that the submit button is rendered on the view.
Upon changing the selected value for the user role, 'update_authorizations' method is called from participants controller which passes the participant id as a parameter to the method to change it's role in the database. The selected role is passed as a parameter 'authorization' to the update authorization method that updates the can_submit, can_take_quiz, and can_review flags appropriately for each role as described above for the selected participant id.

Implementing the above mentioned changes, allows the instructor to change the value of role in the dropdown which retains the corresponding record on tap of the Submit button. We have verified that the changes in the above mentioned flags are reflected in the database. The instructor will be presented with a success message on changing the role of the selected participant, on clicking submit. The instructor can revisit the page and expect the updated value to be retained. Both the problems listed above are taken care of such as the instructor is facilitated with an option to change the participant, as well as knows that the change made will be durable.

===Snapshots after the changes===

* Submit button has been added to each row of assignment participants
 
[[File:Screenshot Submit Added 1.png]]
 
* Change the "Reader" to "Submitter", on the first record and click on submit. Changes have been persisted. Flash message confirmation is also provided to the Instructor to let him/her know of the change.
 
[[File:Screenshot submitter saved 2.png]]
 

===Additional Changes===
(These changes were not part of the assigned issue E1963, these are additional issues that we encountered while fixing E1963)

In addition to the above-mentioned issue, we fixed a few other issues that we observed , which were relevant to Assignment Participant and Course Participant Controllers, namely:

'''1. Export Details''' in Assignment Participants view: We noticed that a a blank csv file was getting generated on exporting detail button in Manage Assignments. We discovered that the reason for this issue is that in the import method, the model defined was that of AssignmentParticipant whereas all the parsing methods for export were present in Assignment model. We did the required changes, tested the functionality and note that this is working fine now.
The changes for this are made in the common module - export_file_controller.rb following which the export and export_details methods are now called from the assignment.rb as opposed to assignment_participant.rb where there are no export methods and their corresponding implementations.
Now, the Export Detail button generates a comma-seperated file with the following headers:
* Assignment Name
* Assignment Instructor
* Team ID / Author ID
* Reviewee (Team / Student Name)
* Reviewer
* Question / Criterion
* Question ID
* Answer / Comment ID
* Answer / Comment
* Score

'''2. ''' Along with the previous issue, we found that since the partials were shared among Assignment Participant and Course Participant, Course Participant also had the Export Details section and the corresponding button. However, it is not required and we believe that it should be removed from the view. We consulted Dr. Gehringer and based on his feedback as well, we removed the semi-view consisting of "Export Details" from Course Participant. The changes are made in the file "start.html.erb" by using conditional rendering of the partial based on the model name.

'''The view before change:'''

 
[[File:Screen Shot Before Remove Export Detauls.png]]
 

'''The view after change:'''

 
[[File:Screen Shot After Remove Export Details.png]]
 

'''3. Missing Handle: Assignment Participant''' on adding a new Assignment Participant: We observed that when a new assignment participant is created, if a user already exists with the username, the existing user is added to that Assignment and his existing handle attribute in Users table is mapped to the handle attribute in Participants table. However, if a new user is added not currently in the Users table, a new entry is created first in the Users table and is then replicated in the Participants table. Although, we noticed that the handle attribute in Participants table was coming as null. We fixed this issue by making change in the define_attributes method in ImportFileHelper.rb.

'''4. Import Assignment Participants''' was not working - It is expected that if a user does not exist in the system, on importing assignment participants, a user will be created and he/she will be added to the assignment as a participant. With the current implementation, the user was getting created, however corresponding AssignmentParticipant was not getting created due to a validation with respect to handle. We have fixed this issue by setting the handle in AssignmentParticipants to be the same as the name of the user created (in accordance with the current functionality - when a user is added as an AssignmentParticipant from the UI). This facilitates us to import AssignmentParticipants.
The mandatory minimal attributes required to import an assignment participant are :
* Username
* Full name
* Email id
* Password.

'''5. The role in the Assignment Participant view''' doesn't have a header unlike all the other attributes on the view. We added a header for the role, thereby increasing the readability and consistency on the UI. The required changes are made in the partial "_user_list.html"

'''The view before change:'''

 
[[File:Screen Shot Before Participant AP.png]]
 

'''The view after change:'''

 
[[File:Screen Shot After Participant AP.png]]
 

'''6. The role in the Course Participant view''' doesn't have a header unlike all the other attributes on the view. We added a header for the role, thereby increasing the readability and consistency on the UI. The required changes are made in the partial "_user_list.html"

'''The view before change:'''

 
[[File:Screen Shot Before Participant CP.png]]
 

'''The view after change:'''

 
[[File:Screen Shot After Participant Role CP.png]]
 

===Test Plan===
Rspec test has been added to check the update authorizations functionality in the participants_controller_spec.rb. The test verifies the change of flags mentioned above as per the authorization of the user. The tests also checks whether the expected flash message is visible on the UI. Code coverage is '''100%''' for all the code that we have added in the controllers, as part of this project.

To make sure we covered all of our code (100%) with test cases we used Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually running the test case, the SimpleCov gem highlights the lines of code which are covered by our test cases with green color, and with red color for lines for which are not covered by our test cases. The image below shows the output of SimpleCov gem for the file participants_controller_spec.rb.

'''Please see the coverage of the code as shown in the screenshot below:'''

 
[[File:Screen Shot code coverage.png]]
 

'''Please find the tests added below:'''
<pre>
describe '#validate_authorizations' do
#Test case for successful update of participant to reviewer, expects the success flash message
it 'updates the authorizations for the participant to make them reviewer' do
allow(Participant).to receive(:find).with('1').and_return(participant)
params = {authorization: 'reviewer', id: 1}
session = {user: instructor}
get :update_authorizations, params, session
expect(flash[:success]).to eq 'The role of the selected participants has been successfully updated.'
expect(participant.can_review).to eq(true)
expect(participant.can_submit).to eq(false)
expect(participant.can_take_quiz).to eq(false)
end

#Test for case where we expect to encounter an error in update_attributes method
it ' throws an exception while validating authorizations' do
allow(Participant).to receive(:find).with('1').and_return(participant)
allow(participant).to receive(:update_attributes).and_raise(StandardError)
params = {authorization: 'reviewer', id: 1}
session = {user: instructor}
get :update_authorizations, params, session
expect(flash[:error]).to eq 'The update action failed.'
end

end
</pre>

===Team===
#Natansh Negi (nnegi2@ncsu.edu)
#Richa Dua (rdua2@ncsu.edu)
#Roshani Narasimhan (rnarasi2@ncsu.edu)
'''Mentor:''' Sharique Khan (mkhan8@ncsu.edu)

===References===
* [https://github.com/expertiza/expertiza Link to expertiza]
* [https://github.com/RoshaniN/expertiza-team-622.git Link to changes E1963]
* [https://github.com/expertiza/expertiza/pull/1533 Link to Pull request]
* [http://152.46.19.56:8080/ Link to deployed application on VCL]

CSC/ECE 517 Fall 2019 - E1963. Changing assignment participant role

2019-11-07T00:48:27Z

Nnegi2: /* Test Plan */

= E1963 Changing assignment Participant role=

===Background===

* E1963 This project aims to enable the instructor to change the role of an assignment participant. There are two ways to add a new assignment participant, first being through the Add button on the assignment participant page. Another way is to import via a spreadsheet with the list of users that are to be added. The motivation of E1963 was to enable the instructors adding these users using either of the methods mentioned above to change these users' role. A user can have one of the following roles - participant, reader, reviewer, submitter.

* The existing UI had the a dropdown that displayed the role of the user, we have added a Submit button below each dropdown to enable the instructor to change the role of the user. On clicking the submit button, the role associated with that user is changed in the persistent storage. We have also added a flash message which confirms the change to the user.

The following issues were targeted in this project:
* '''#1:''' The instructor does not have the option to change the role of the user, once he/she has been added to the assignment. Thus, if the instructor wishes to change the role of a user from say a reviewer to a submitter, he/she is not able to save the changes.
* '''#2:''' With the changes made for the issue mentioned above, the instructor will be able to save the changes manually. We would like to maintain the same behavior when the assignment participants are imported from excel. Upon creating a new user using an Excel import, the user should have the role of a participant by default. An instructor was then unable to change the role of the assignment participant.

===Navigation===
Manage Assignments -> Add new participant icon under Actions

===Current implementation===
For each of the assignment participant record, there is a dropdown which contains the role of the participant. When the instructor attempts to change the value in the dropdown, it is not reflected in the backend, as there is no call associated with it, to submit the changes. Thus when the user revisits the page, the changes would he would have made are not retained.

Authorization of the user is based on the flags can_submit, can_review and can_take_quiz flags, which are set to be true or false based on the role of the user. By default, the user is assigned the role of a participant in any assignment. Thus, the goal is to modify these flags and save them in the database when the role of the assignment participant is changed, so that it is a persistent change.
Authorization of the users based on the flags can be deduced as follows:
* Participant has can_submit=true, can_review=true and can_take_quiz=true
* Reader has can_submit= false, can_review=true and can_take_quiz= true
* Submitter has can_submit=true, can_review= false and can_take_quiz=false
* Reviewer has can_submit=false, can_review= true and can_take_quiz=false

Problems:
* 1. There is no way to change the role of the user, once the user has been added to the assignment as a participant. (Submit button now resolves this issue.)
* 2. Instructor is not given any confirmation that the role of the participant has been reverted to the original value once he/she navigates somewhere else. This is misleading for an instructor as the he/she might be under the impression that the changes he/she made have been saved. (Flash message now lets the user know about the change.)

===Snapshots depicting the issue===

* As an Instructor, go to Manage Assignments
 
[[File:Screenshot ManageAssignments.png]]
 

* Click on add participant
 
[[File:Screenshot AssignmentParticipants copy.png]]
 

* Note that the user on the first record is currently a "Reader"
 
[[File:Screenshot Currently Reader.png]]
 

* Change the role of the "Reader" to say "Submitter"
 
[[File:Screenshot Submitter.png]]
 

* Refresh or re-navigate to this page and note that the changes are reverted
 
[[File:Screenshot back to Reader.png]]
 

===Implementation===

Changes are made in the partial for participants "_participant.rb", so that the submit button is rendered on the view.
Upon changing the selected value for the user role, 'update_authorizations' method is called from participants controller which passes the participant id as a parameter to the method to change it's role in the database. The selected role is passed as a parameter 'authorization' to the update authorization method that updates the can_submit, can_take_quiz, and can_review flags appropriately for each role as described above for the selected participant id.

Implementing the above mentioned changes, allows the instructor to change the value of role in the dropdown which retains the corresponding record on tap of the Submit button. We have verified that the changes in the above mentioned flags are reflected in the database. The instructor will be presented with a success message on changing the role of the selected participant, on clicking submit. The instructor can revisit the page and expect the updated value to be retained. Both the problems listed above are taken care of such as the instructor is facilitated with an option to change the participant, as well as knows that the change made will be durable.

===Snapshots after the changes===

* Submit button has been added to each row of assignment participants
 
[[File:Screenshot Submit Added 1.png]]
 
* Change the "Reader" to "Submitter", on the first record and click on submit. Changes have been persisted. Flash message confirmation is also provided to the Instructor to let him/her know of the change.
 
[[File:Screenshot submitter saved 2.png]]
 

===Additional Changes===
(These changes were not part of the assigned issue E1963, these are additional issues that we encountered while fixing E1963)

In addition to the above-mentioned issue, we fixed a few other issues that we observed , which were relevant to Assignment Participant and Course Participant Controllers, namely:

'''1. Export Details''' in Assignment Participants view: We noticed that a a blank csv file was getting generated on exporting detail button in Manage Assignments. We discovered that the reason for this issue is that in the import method, the model defined was that of AssignmentParticipant whereas all the parsing methods for export were present in Assignment model. We did the required changes, tested the functionality and note that this is working fine now.
The changes for this are made in the common module - export_file_controller.rb following which the export and export_details methods are now called from the assignment.rb as opposed to assignment_participant.rb where there are no export methods and their corresponding implementations.
Now, the Export Detail button generates a comma-seperated file with the following headers:
* Assignment Name
* Assignment Instructor
* Team ID / Author ID
* Reviewee (Team / Student Name)
* Reviewer
* Question / Criterion
* Question ID
* Answer / Comment ID
* Answer / Comment
* Score

'''2. ''' Along with the previous issue, we found that since the partials were shared among Assignment Participant and Course Participant, Course Participant also had the Export Details section and the corresponding button. However, it is not required and we believe that it should be removed from the view. We consulted Dr. Gehringer and based on his feedback as well, we removed the semi-view consisting of "Export Details" from Course Participant. The changes are made in the file "start.html.erb" by using conditional rendering of the partial based on the model name.

'''The view before change:'''

 
[[File:Screen Shot Before Remove Export Detauls.png]]
 

'''The view after change:'''

 
[[File:Screen Shot After Remove Export Details.png]]
 

'''3. Missing Handle: Assignment Participant''' on adding a new Assignment Participant: We observed that when a new assignment participant is created, if a user already exists with the username, the existing user is added to that Assignment and his existing handle attribute in Users table is mapped to the handle attribute in Participants table. However, if a new user is added not currently in the Users table, a new entry is created first in the Users table and is then replicated in the Participants table. Although, we noticed that the handle attribute in Participants table was coming as null. We fixed this issue by making change in the define_attributes method in ImportFileHelper.rb.

'''4. Import Assignment Participants''' was not working - It is expected that if a user does not exist in the system, on importing assignment participants, a user will be created and he/she will be added to the assignment as a participant. With the current implementation, the user was getting created, however corresponding AssignmentParticipant was not getting created due to a validation with respect to handle. We have fixed this issue by setting the handle in AssignmentParticipants to be the same as the name of the user created (in accordance with the current functionality - when a user is added as an AssignmentParticipant from the UI). This facilitates us to import AssignmentParticipants.
The mandatory minimal attributes required to import an assignment participant are :
* Username
* Full name
* Email id
* Password.

'''5. The role in the Assignment Participant view''' doesn't have a header unlike all the other attributes on the view. We added a header for the role, thereby increasing the readability and consistency on the UI. The required changes are made in the partial "_user_list.html"

'''The view before change:'''

 
[[File:Screen Shot Before Participant AP.png]]
 

'''The view after change:'''

 
[[File:Screen Shot After Participant AP.png]]
 

'''6. The role in the Course Participant view''' doesn't have a header unlike all the other attributes on the view. We added a header for the role, thereby increasing the readability and consistency on the UI. The required changes are made in the partial "_user_list.html"

'''The view before change:'''

 
[[File:Screen Shot Before Participant CP.png]]
 

'''The view after change:'''

 
[[File:Screen Shot After Participant Role CP.png]]
 

===Test Plan===
Rspec test has been added to check the update authorizations functionality in the participants_controller_spec.rb. The test verifies the change of flags mentioned above as per the authorization of the user. The tests also checks whether the expected flash message is visible on the UI. Code coverage is '''100%''' for all the code that we have added in the controllers, as part of this project.

'''Please see the coverage of the code as shown in the screenshot below:'''

 
[[File:Screen Shot code coverage.png]]
 

We checked the code coverage using Ruby Code Coverage plugin and SimpleCov gem.

'''Please find the tests added below:'''
<pre>
describe '#validate_authorizations' do
#Test case for successful update of participant to reviewer, expects the success flash message
it 'updates the authorizations for the participant to make them reviewer' do
allow(Participant).to receive(:find).with('1').and_return(participant)
params = {authorization: 'reviewer', id: 1}
session = {user: instructor}
get :update_authorizations, params, session
expect(flash[:success]).to eq 'The role of the selected participants has been successfully updated.'
expect(participant.can_review).to eq(true)
expect(participant.can_submit).to eq(false)
expect(participant.can_take_quiz).to eq(false)
end

#Test for case where we expect to encounter an error in update_attributes method
it ' throws an exception while validating authorizations' do
allow(Participant).to receive(:find).with('1').and_return(participant)
allow(participant).to receive(:update_attributes).and_raise(StandardError)
params = {authorization: 'reviewer', id: 1}
session = {user: instructor}
get :update_authorizations, params, session
expect(flash[:error]).to eq 'The update action failed.'
end

end
</pre>

===Team===
#Natansh Negi (nnegi2@ncsu.edu)
#Richa Dua (rdua2@ncsu.edu)
#Roshani Narasimhan (rnarasi2@ncsu.edu)
'''Mentor:''' Sharique Khan (mkhan8@ncsu.edu)

===References===
* [https://github.com/expertiza/expertiza Link to expertiza]
* [https://github.com/RoshaniN/expertiza-team-622.git Link to changes E1963]
* [https://github.com/expertiza/expertiza/pull/1533 Link to Pull request]
* [http://152.46.19.56:8080/ Link to deployed application on VCL]

CSC/ECE 517 Fall 2019 - E1963. Changing assignment participant role

2019-11-06T21:02:35Z

Nnegi2: /* Test Plan */

= E1963 Changing assignment Participant role=

===Background===

* E1963 This project aims to enable the instructor to change the role of an assignment participant. There are two ways to add a new assignment participant, first being through the Add button on the assignment participant page. Another way is to import via a spreadsheet with the list of users that are to be added. The motivation of E1963 was to enable the instructors adding these users using either of the methods mentioned above to change these users' role. A user can have one of the following roles - participant, reader, reviewer, submitter.

* The existing UI had the a dropdown that displayed the role of the user, we have added a Submit button below each dropdown to enable the instructor to change the role of the user. On tapping the submit button, the role associated with that user is changed in the persistent storage. We have also added a flash message which confirms the change to the user.

The following issues were targeted in this project:
* '''#1:''' The instructor does not have the option to change the role of the user, once he/she has been added to the assignment. Thus, if the instructor wishes to change the role of a user from say a reviewer to a submitter, he/she is not able to save the changes.
* '''#2:''' With the changes made for the issue mentioned above, the instructor will be able to save the changes manually. We would like to maintain the same behavior when the assignment participants are imported from excel. Upon creating a new user using an Excel import, the user should have the role of a participant by default. An instructor was then unable to change the role of the assignment participant.

===Navigation===
Manage Assignments -> Add new participant

===Current implementation===
For each of the assignment participant record, there is a dropdown which contains the role of the participant. When the instructor attempts to change the value in the dropdown, it is not reflected in the backend, as there is no call associated with it, to submit the changes. Thus when the user revisits the page, the changes would he would have made are not retained.

Authorization of the user is based on the flags can_submit, can_review and can_take_quiz flags, which are set to be true or false based on the role of the user. By default, the user is assigned the role of a participant in any assignment. Thus, the goal is to modify these flags and save them in the database when the role of the assignment participant is changed, so that it is a persistent change.
Authorization of the users based on the flags can be deduced as follows:
* Participant has can_submit=true, can_review=true and can_take_quiz=true
* Reader has can_submit= false, can_review=true and can_take_quiz= true
* Submitter has can_submit=true, can_review= false and can_take_quiz=false
* Reviewer has can_submit=false, can_review= true and can_take_quiz=false

Problems:
* 1. There is no way to change the role of the user, once the user has been added to the assignment as a participant. (Submit button now resolves this issue.)
* 2. Instructor is not given any confirmation that the role of the participant has been reverted to the original value once he/she navigates somewhere else. This is misleading for an instructor as the he/she might be under the impression that the changes he/she made have been saved. (Flash message now lets the user know about the change.)

===Snapshots depicting the issue===

* As an Instructor, go to Manage Assignments
 
[[File:Screenshot ManageAssignments.png]]
 

* Click on add participant
 
[[File:Screenshot AssignmentParticipants copy.png]]
 

* Note that the user on the first record is currently a "Reader"
 
[[File:Screenshot Currently Reader.png]]
 

* Change the role of the "Reader" to say "Submitter"
 
[[File:Screenshot Submitter.png]]
 

* Refresh or re-navigate to this page and note that the changes are reverted
 
[[File:Screenshot back to Reader.png]]
 

===Implementation===

Changes are made in the partial for participants "_participant.rb", so that the submit button is rendered on the view.
Upon changing the selected value for the user role, 'update_authorizations' method is called from participants controller which passes the participant id as a parameter to the method to change it's role in the database. The selected role is passed as a parameter 'authorization' to the update authorization method that updates the can_submit, can_take_quiz, and can_review flags appropriately for each role as described above for the selected participant id.

Implementing the above mentioned changes, allows the instructor to change the value of role in the dropdown which retains the corresponding record on tap of the Submit button. We have verified that the changes in the above mentioned flags are reflected in the database. The instructor will be presented with a success message on changing the role of the selected participant, on clicking submit. The instructor can revisit the page and expect the updated value to be retained. Both the problems listed above are taken care of such as the instructor is facilitated with an option to change the participant, as well as knows that the change made will be durable.

===Snapshots after the changes===

* Submit button has been added to each row of assignment participants
 
[[File:Screenshot Submit Added 1.png]]
 
* Change the "Reader" to "Submitter", on the first record and click on submit. Changes have been persisted. Flash message confirmation is also provided to the Instructor to let him/her know of the change.
 
[[File:Screenshot submitter saved 2.png]]
 

===Additional Changes===
(These changes were not part of the assigned issue E1963, these are additional issues that we encountered while fixing E1963)

In addition to the above-mentioned issue, we fixed a few other issues that we encountered , which were relevant to Assignment Participant and Course Participant Controllers, namely:

'''1. Export Details''' in Assignment Participants view: We noticed that a a blank csv file was getting generated on exporting detail button in Manage Assignments. We discovered that the reason for this issue is that in the import method, the model defined was that of AssignmentParticipant whereas all the parsing methods for export were present in Assignment model. We did the required changes, tested the functionality and note that this is working fine now.
The changes for this are made in the common module - export_file_controller.rb following which the export and export_details methods are now called from the assignment.rb as opposed to assignment_participant.rb where there are no export methods and their corresponding implementations.
Now, the Export Detail button generates a comma-seperated file with the following headers:
* Assignment Name
* Assignment Instructor
* Team ID / Author ID
* Reviewee (Team / Student Name)
* Reviewer
* Question / Criterion
* Question ID
* Answer / Comment ID
* Answer / Comment
* Score

'''2. ''' Along with the previous issue, we found that since the partials were shared among Assignment Participant and Course Participant, Course Participant also had the Export Details section and the corresponding button. However, it is not required and we believe that it should be removed from the view. We consulted Dr. Gehringer and based on his feedback as well, we removed the semi-view consisting of "Export Details" from Course Participant. The changes are made in the file "start.html.erb" by using conditional rendering of the partial based on the model name.

The view before change:
 
[[File:Screenshot submitter saved 2.png]]
 

The view after change:
 
[[File:Screenshot submitter saved 2.png]]
 

'''3. Missing Handle: Assignment Participant''' on adding a new Assignment Participant: We observed that when a new assignment participant is created, if a user already exists with the username, the existing user is added to that Assignment and his existing handle attribute in Users table is mapped to the handle attribute in Participants table. However, if a new user is added not currently in the Users table, a new entry is created first in the Users table and is then replicated in the Participants table. Although, we noticed that the handle attribute in Participants table was coming as null. We fixed this issue by making change in the define_attributes method in ImportFileHelper.rb.

'''4. Import Assignment Participants''' was not working - It is expected that if a user does not exist in the system, on importing assignment participants, a user will be created and he/she will be added to the assignment as a participant. With the current implementation, the user was getting created, however corresponding AssignmentParticipant was not getting created due to a validation with respect to handle. We have fixed this issue by setting the handle in AssignmentParticipants to be the same as the name of the user created (in accordance with the current functionality - when a user is added as an AssignmentParticipant from the UI). This facilitates us to import AssignmentParticipants.
The mandatory minimal attributes required to import an assignment participant are :
* Username
* Full name
* Email id
* Password.

'''5. The role in the Assignment Participant view''' doesn't have a header unlike all the other attributes on the view. We added a header for the role, thereby increasing the readability and consistency on the UI. The required changes are made in the partial "_user_list.html"

The view before change:
 
[[File:Screen Shot Before Participant AP.png]]
 

The view after change:
 
[[File:Screen Shot After Participant AP.png]]
 

'''6. The role in the Course Participant view''' doesn't have a header unlike all the other attributes on the view. We added a header for the role, thereby increasing the readability and consistency on the UI. The required changes are made in the partial "_user_list.html"

The view before change:
 
[File:Screen Shot Before Participant CP.png]
 

The view after change:
 
[[File:Screen Shot After Participant Role CP.png]]
 

===Test Plan===
Rspec test has been added to check the update authorizations functionality in the participants_controller_spec.rb. The test verifies the change of flags mentioned above as per the authorization of the user. The tests also checks whether the expected flash message is visible on the UI. Code coverage is 100% for all the code that we have added as part of this project. We checked the code coverage using Ruby Code Coverage plugin and SimpleCov gem.
 
[File:Screen Shot Before Participant CP.png]
 

===Team===
#Natansh Negi (nnegi2@ncsu.edu)
#Richa Dua (rdua2@ncsu.edu)
#Roshani Narasimhan (rnarasi2@ncsu.edu)
'''Mentor:''' Sharique Khan (mkhan8@ncsu.edu)

===References===
* [https://github.com/expertiza/expertiza Link to expertiza]
* [https://github.com/RoshaniN/expertiza-team-622.git Link to changes E1963]
* [https://github.com/expertiza/expertiza/pull/1533 Link to Pull request]
* [http://152.46.19.56:8080/ Link to deployed application on VCL]