Expertiza_Wiki - User contributions [en]

E2157. Fix issues related to deadlines and late policies

2021-11-30T19:18:13Z

Swaghe:

__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). The team found some issues in the current implementation which either cause errors are completely not functional. The goal of this project is to eliminate these issues by making necessary changes and adding new test cases which cover all scenarios.

====Issues with the Current Implementation====
The following issues have been raised in the current implementation:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”.

[[File:Qissue1.png|650px]]

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

[[File:Qissue2.png|650px]]

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

[[File:Qissue31.png|650px]]

[[File:Qissue32.png|650px]]

* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work.

[[File:Issue41.png|650px]]

[[File:Issue42.png|650px]]

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

====Refactoring and Design Patterns====
Since our goal is to fix existing functionalities we will not be updating the existing design patterns being employed in the code. Yet, we would like to discuss what makes these refactoring important. Refactoring is a systematic process of improving code without creating new functionality. Thus, a key to the success of our project is ensuring everything that was working before our changes work even after our changes have been added. To ensure this, we will continue to test the system after each issue has been fixed. This will allow us to ensure two things:

* We are only changing what we set out to change when fixing a particular issue.
* We are not breaking what was working before we deployed our fix.

We believe at the end our changes will increase the quality of Expertiza and improve the experience for users an developers alike.

==Project Scope==
[[File:Rsz late policy.png|600px]]
<br>
All the issues raised mainly exist in the "Due Dates" tab on the "Edit Assignment" page.
* '''Issue 1''' - Change "penalty policy" to "late policy" on all the relevant UI screens (app/views/late_policies).
* '''Issue 2''' - Analyze and fix required function and write appropriate test cases (late_policies_controller.rb).
* '''Issue 3''' - Analyze and fix required function and write appropriate test cases (late_policies_controller.rb).
* '''Issue 4''' - Analyze and fix required function and write appropriate test cases (late_policies_controller.rb).
* '''Issue 5''' - Write new test cases for late_policies_controller.rb and late_policy.rb.

==Problem description, Approach & Fix==

<h4> Issue 1: Renaming penalty policy to late policy</h4>
'''Problem Description: ''' Usage of different terms for the same thing causes ambiguity and can lead to unfortunate errors. In this instance having two different terms for "late policy" will cause confusion when instructors are creating assignments.

'''Fix:''' To avoid confusion, use “late policy” exclusively.
'''Code Snippet : '''

[[File:Issue1A.png]]

<h4> Issue 2: Issue 2: Late policies cannot be created without raising an error </h4>
'''Problem Description: ''' The current implementation throws errors whenever late policies are created. Most of these errors are from the end of the system and not users. This is not desirable from our system as it should be able to handle internal errors and throw error messages only when they are absolutely required.

'''Fix:'''
<ul>
<li>Ensure that all errors being raised are fixed. This will be achieved by modifying existing code and bringing new checks as and when required.0</li>
<li>Added a flash error message in the create function of late_policies_controller.rb</li>
</ul>
'''Code Snippet : '''

[[File:Issue2A.png]]

<h4> Issue 3: After creating a late policy, the “back” link does not take the user back to editing the assignment.</h4>
'''Problem Description: ''' The "back" button functionality is broken. In an extensive system like ours, such issues can make our users irritable and do not provide them with the best user experience. These navigation buttons are an important part of the system and should take the users to correct pages.

'''Fix:''' Ensure that on click of the back button, the user is taken back to the assignment page. To achieve this, we have added the assignment reference in the current session.

'''Code Snippet : '''

[[File:issue3A.png]]

<h4>Issue 4: The "+" and "-" buttons for Show/Hide Date Updater do not work.</h4>
'''Problem Description: ''' If I create an assignment by copying an old assignment, the due dates are copied too. It is likely that I want the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.). To avoid the need to edit all the deadlines manually, Expertiza has a date updater. Currently, the broken "+" and "-" button make it hard for our users to take full advantage of this functionality.

'''Fix:''' Editing the code linked to these button should allow us to ensure that users can increment and decrement between dates as per requirements.We found out that this functionality is already working, however we added an information icon so that it is well understood by the user how to use this.

'''Code Snippet : '''

[[File:issue4A.png]]

<h4>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.</h4>
'''Problem Description: ''' The purpose of a test case is to determine if different features within a system are performing as expected and to confirm that the system satisfies all related standards, guidelines, and customer requirements. The process of writing a test case can also help reveal errors or defects within the system.

'''Fix:'''
<ul>
<li>Added test file for late_policies_controller_spec.rb with appropriate test cases</li>
<li>Added test file for late_policies_spec.rb with appropriate test cases
</ul>

===Test Plan===
----
'''''Before fix'''''
<br>
<br>
'''Manual Testing ()'''

#[https://drive.google.com/file/d/1gpW2Y6mw-ctg5EZE4JZoSLS5mjJuIg1S/view?usp=sharing Working Demo Video]

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>

'''''After fix'''''

The new code changes does not break existing functionality. Please check out below video which shows how all the five issues are being addressed :

#[https://drive.google.com/file/d/1gpW2Y6mw-ctg5EZE4JZoSLS5mjJuIg1S/view?usp=sharing Working Demo]

'''Automated Testing Using RSpec'''

We created two new test files, late_policy_spec.rb and late_policies_controller_spec.rb which cover test scenarios for late_policy.rb and late_policies_controller.rb repesctively.

'''late_policy_spec.rb'''

This test suite covers the two functions available in the model. Our test ensures that the model functions as expected. Most of the corner cases are being covered by controller test and thus the key to this test suite is ensuring all functionalities function as expected.

[[File:Test_1.png|600px]]

The first function in the model is for checking if for a particular instructor, the policy name already exists. For this scenario, there are two possible outcomes :
* Policy name already exists under an instructor.
* Policy name does not exists under an instructor.

Our test cases cover both of these scenarios.

[[File:Test_2.png|600px]]
[[File:Test_3.png|600px]]

The second method in this controller checks if penalty points are being updated correctly or not. One key aspect to testing this function was the mocking of the helper method. Our model depends on a helper file to update penalty points based on certain factors. Since the functionality of the model should be independent of helper behavior, we have mocked that call. The calculation of penalty is based on the type of the deadline which can have 4 possible values :
* nil
* 1
* 2
* 5

Based on each none or one of the penalty points from submission, review or meta_review gets updated. Our test suite goes through each and ensures the correct one is being updated.

'''late_policies_controller_spec.rb'''
Our controller test ensures that the controller works as expected. We have covered the test cases for each method present in the controller, Moreover, we tried to cover most of the corner cases. We have total of 14 controller test case and detailed test cases can be checked out in our pull request (#[https://github.com/expertiza/expertiza/pull/2127 Pull Request]).

Following are few test cases :

1.) This test case covers the scenario where the penalty per unit exceeds the max penalty for an assignment.

[[File:MaxPenaltyLess.png]]

2.) Trying to create/update policy which already exists.

[[File:SamePolicy.png]]

[[File:createSamePolicy.png]]

3.) Delete the policy.

[[File:DestroyPolicy.png]]

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

Test coverage has been increased by 0.6 percentage :

[[File:Coverage.png]]

==Milestones==
'''10/25''' – Project Selection

'''11/03''' – Develop Project Design Document

'''11/06''' – Update Project Design Document based on feedback from Round 1

==Project Mentors==
*Tirth Patel

==Team Members==
* Anmol Lunavat

* Shubham Waghe

* Vishal Sharma

==Useful Links==
===E2157===
#[https://github.com/wshubham/expertiza/tree/beta GitHub forked repository]
#[https://github.com/expertiza/expertiza/pull/2127 Pull Request]

===Expertiza===
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ Live Expertiza website]

E2157. Fix issues related to deadlines and late policies

2021-11-30T19:15:10Z

Swaghe:

__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). The team found some issues in the current implementation which either cause errors are completely not functional. The goal of this project is to eliminate these issues by making necessary changes and adding new test cases which cover all scenarios.

====Issues with the Current Implementation====
The following issues have been raised in the current implementation:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”.

[[File:Qissue1.png|650px]]

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

[[File:Qissue2.png|650px]]

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

[[File:Qissue31.png|650px]]

[[File:Qissue32.png|650px]]

* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work.

[[File:Issue41.png|650px]]

[[File:Issue42.png|650px]]

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

====Refactoring and Design Patterns====
Since our goal is to fix existing functionalities we will not be updating the existing design patterns being employed in the code. Yet, we would like to discuss what makes these refactoring important. Refactoring is a systematic process of improving code without creating new functionality. Thus, a key to the success of our project is ensuring everything that was working before our changes work even after our changes have been added. To ensure this, we will continue to test the system after each issue has been fixed. This will allow us to ensure two things:

* We are only changing what we set out to change when fixing a particular issue.
* We are not breaking what was working before we deployed our fix.

We believe at the end our changes will increase the quality of Expertiza and improve the experience for users an developers alike.

==Project Scope==
[[File:Rsz late policy.png|600px]]
<br>
All the issues raised mainly exist in the "Due Dates" tab on the "Edit Assignment" page.
* '''Issue 1''' - Change "penalty policy" to "late policy" on all the relevant UI screens (app/views/late_policies).
* '''Issue 2''' - Analyze and fix required function and write appropriate test cases (late_policies_controller.rb).
* '''Issue 3''' - Analyze and fix required function and write appropriate test cases (late_policies_controller.rb).
* '''Issue 4''' - Analyze and fix required function and write appropriate test cases (late_policies_controller.rb).
* '''Issue 5''' - Write new test cases for late_policies_controller.rb and late_policy.rb.

==Problem description, Approach & Fix==

<h3> Issue 1: Renaming penalty policy to late policy</h3>
'''Problem Description: ''' Usage of different terms for the same thing causes ambiguity and can lead to unfortunate errors. In this instance having two different terms for "late policy" will cause confusion when instructors are creating assignments.

'''Fix:''' To avoid confusion, use “late policy” exclusively.
'''Code Snippet : '''

[[File:Issue1A.png]]

<h3> Issue 2: Issue 2: Late policies cannot be created without raising an error </h3>
'''Problem Description: ''' The current implementation throws errors whenever late policies are created. Most of these errors are from the end of the system and not users. This is not desirable from our system as it should be able to handle internal errors and throw error messages only when they are absolutely required.

'''Fix:'''
<ul>
<li>Ensure that all errors being raised are fixed. This will be achieved by modifying existing code and bringing new checks as and when required.0</li>
<li>Added a flash error message in the create function of late_policies_controller.rb</li>
</ul>
'''Code Snippet : '''

[[File:Issue2A.png]]

<h3> Issue 3: After creating a late policy, the “back” link does not take the user back to editing the assignment.</h3>
'''Problem Description: ''' The "back" button functionality is broken. In an extensive system like ours, such issues can make our users irritable and do not provide them with the best user experience. These navigation buttons are an important part of the system and should take the users to correct pages.

'''Fix:''' Ensure that on click of the back button, the user is taken back to the assignment page. To achieve this, we have added the assignment reference in the current session.

'''Code Snippet : '''

[[File:issue3A.png]]

<h3>Issue 4: The "+" and "-" buttons for Show/Hide Date Updater do not work.</h3>
'''Problem Description: ''' If I create an assignment by copying an old assignment, the due dates are copied too. It is likely that I want the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.). To avoid the need to edit all the deadlines manually, Expertiza has a date updater. Currently, the broken "+" and "-" button make it hard for our users to take full advantage of this functionality.

'''Fix:''' Editing the code linked to these button should allow us to ensure that users can increment and decrement between dates as per requirements.We found out that this functionality is already working, however we added an information icon so that it is well understood by the user how to use this.

'''Code Snippet : '''

[[File:issue4A.png]]

<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>
'''Problem Description: ''' The purpose of a test case is to determine if different features within a system are performing as expected and to confirm that the system satisfies all related standards, guidelines, and customer requirements. The process of writing a test case can also help reveal errors or defects within the system.

'''Fix:'''
<ul>
<li>Added test file for late_policies_controller_spec.rb with appropriate test cases</li>
<li>Added test file for late_policies_spec.rb with appropriate test cases
</ul>

===Test Plan===
----
'''''Before fix'''''
<br>
<br>
'''Manual Testing ()'''

#[https://drive.google.com/file/d/1gpW2Y6mw-ctg5EZE4JZoSLS5mjJuIg1S/view?usp=sharing Working Demo Video]

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>

'''''After fix'''''

The new code changes does not break existing functionality. Please check out below video which shows how all the five issues are being addressed :

#[https://drive.google.com/file/d/1gpW2Y6mw-ctg5EZE4JZoSLS5mjJuIg1S/view?usp=sharing Working Demo]

'''Automated Testing Using RSpec'''

We created two new test files, late_policy_spec.rb and late_policies_controller_spec.rb which cover test scenarios for late_policy.rb and late_policies_controller.rb repesctively.

'''late_policy_spec.rb'''

This test suite covers the two functions available in the model. Our test ensures that the model functions as expected. Most of the corner cases are being covered by controller test and thus the key to this test suite is ensuring all functionalities function as expected.

[[File:Test_1.png|600px]]

The first function in the model is for checking if for a particular instructor, the policy name already exists. For this scenario, there are two possible outcomes :
* Policy name already exists under an instructor.
* Policy name does not exists under an instructor.

Our test cases cover both of these scenarios.

[[File:Test_2.png|600px]]
[[File:Test_3.png|600px]]

The second method in this controller checks if penalty points are being updated correctly or not. One key aspect to testing this function was the mocking of the helper method. Our model depends on a helper file to update penalty points based on certain factors. Since the functionality of the model should be independent of helper behavior, we have mocked that call. The calculation of penalty is based on the type of the deadline which can have 4 possible values :
* nil
* 1
* 2
* 5

Based on each none or one of the penalty points from submission, review or meta_review gets updated. Our test suite goes through each and ensures the correct one is being updated.

'''late_policies_controller_spec.rb'''
Our controller test ensures that the controller works as expected. We have covered the test cases for each method present in the controller, Moreover, we tried to cover most of the corner cases. We have total of 14 controller test case and detailed test cases can be checked out in our pull request (#[https://github.com/expertiza/expertiza/pull/2127 Pull Request]).

Following are few test cases :

1.) This test case covers the scenario where the penalty per unit exceeds the max penalty for an assignment.

[[File:MaxPenaltyLess.png]]

2.) Trying to create/update policy which already exists.

[[File:SamePolicy.png]]

[[File:createSamePolicy.png]]

3.) Delete the policy.

[[File:DestroyPolicy.png]]

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

Test coverage has been increased by 0.6 percentage :

[[File:Coverage.png]]

==Milestones==
'''10/25''' – Project Selection

'''11/03''' – Develop Project Design Document

'''11/06''' – Update Project Design Document based on feedback from Round 1

==Project Mentors==
*Tirth Patel

==Team Members==
* Anmol Lunavat

* Shubham Waghe

* Vishal Sharma

==Useful Links==
===E2157===
#[https://github.com/wshubham/expertiza/tree/beta GitHub forked repository]
#[https://github.com/expertiza/expertiza/pull/2127 Pull Request]

===Expertiza===
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ Live Expertiza website]

File:Issue4A.png

2021-11-30T19:13:48Z

Swaghe:

File:Issue3A.png

2021-11-30T19:11:37Z

Swaghe:

File:Issue2A.png

2021-11-30T19:08:44Z

Swaghe:

File:Issue1A.png

2021-11-30T19:04:46Z

Swaghe:

E2157. Fix issues related to deadlines and late policies

2021-11-30T18:53:26Z

Swaghe:

__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). The team found some issues in the current implementation which either cause errors are completely not functional. The goal of this project is to eliminate these issues by making necessary changes and adding new test cases which cover all scenarios.

====Issues with the Current Implementation====
The following issues have been raised in the current implementation:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”.

[[File:Qissue1.png|650px]]

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

[[File:Qissue2.png|650px]]

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

[[File:Qissue31.png|650px]]

[[File:Qissue32.png|650px]]

* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work.

[[File:Issue41.png|650px]]

[[File:Issue42.png|650px]]

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

====Issues Fixed====
All the above mentioned issues has been fixed, check out below video which shows how all the issues are being addressed :
#[https://drive.google.com/file/d/1gpW2Y6mw-ctg5EZE4JZoSLS5mjJuIg1S/view?usp=sharing Working Demo]

====Refactoring and Design Patterns====
Since our goal is to fix existing functionalities we will not be updating the existing design patterns being employed in the code. Yet, we would like to discuss what makes these refactoring important. Refactoring is a systematic process of improving code without creating new functionality. Thus, a key to the success of our project is ensuring everything that was working before our changes work even after our changes have been added. To ensure this, we will continue to test the system after each issue has been fixed. This will allow us to ensure two things:

* We are only changing what we set out to change when fixing a particular issue.
* We are not breaking what was working before we deployed our fix.

We believe at the end our changes will increase the quality of Expertiza and improve the experience for users an developers alike.

==Project Scope==
[[File:Rsz late policy.png|600px]]
<br>
All the issues raised mainly exist in the "Due Dates" tab on the "Edit Assignment" page.
* '''Issue 1''' - Change "penalty policy" to "late policy" on all the relevant UI screens (app/views/late_policies).
* '''Issue 2''' - Analyze and fix required function and write appropriate test cases (late_policies_controller.rb).
* '''Issue 3''' - Analyze and fix required function and write appropriate test cases (late_policies_controller.rb).
* '''Issue 4''' - Analyze and fix required function and write appropriate test cases (late_policies_controller.rb).
* '''Issue 5''' - Write new test cases for late_policies_controller.rb and late_policy.rb.

==Problem description, Approach & Fix==

<h3> Issue 1: Renaming penalty policy to late policy</h3>
'''Problem Description: ''' Usage of different terms for the same thing causes ambiguity and can lead to unfortunate errors. In this instance having two different terms for "late policy" will cause confusion when instructors are creating assignments.

'''Fix:''' To avoid confusion, use “late policy” exclusively.

<h3> Issue 2: Issue 2: Late policies cannot be created without raising an error </h3>
'''Problem Description: ''' The current implementation throws errors whenever late policies are created. Most of these errors are from the end of the system and not users. This is not desirable from our system as it should be able to handle internal errors and throw error messages only when they are absolutely required.

'''Fix:'''
<ul>
<li>Ensure that all errors being raised are fixed. This will be achieved by modifying existing code and bringing new checks as and when required.0</li>
<li>Added a flash error message in the create function of late_policies_controller.rb</li>
</ul>

<h3> Issue 3: After creating a late policy, the “back” link does not take the user back to editing the assignment.</h3>
'''Problem Description: ''' The "back" button functionality is broken. In an extensive system like ours, such issues can make our users irritable and do not provide them with the best user experience. These navigation buttons are an important part of the system and should take the users to correct pages.

'''Fix:''' Ensure that on click of the back button, the user is taken back to the assignment page.

<h3>Issue 4: The "+" and "-" buttons for Show/Hide Date Updater do not work.</h3>
'''Problem Description: ''' If I create an assignment by copying an old assignment, the due dates are copied too. It is likely that I want the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.). To avoid the need to edit all the deadlines manually, Expertiza has a date updater. Currently, the broken "+" and "-" button make it hard for our users to take full advantage of this functionality.

'''Fix:''' Editing the code linked to these button should allow us to ensure that users can increment and decrement between dates as per requirements.

<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>
'''Problem Description: ''' The purpose of a test case is to determine if different features within a system are performing as expected and to confirm that the system satisfies all related standards, guidelines, and customer requirements. The process of writing a test case can also help reveal errors or defects within the system.

'''Fix:'''
<ul>
<li>Add test file for late_policies_controller_spec.rb with appropriate test cases</li>
<li>Add test file for late_policies_spec.rb with appropriate test cases
</ul>

==Expected Results==
We expect the new code changes should not break existing functionality and the following results upon completion:
<br>
* '''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.
<br>
[[File:Hitissue11.png|650px]]
<br>
* '''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.
<br>
[[File:Hitissue2.png|650px]]
<br>
* '''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.
<br>
[[File:Hitissue3.png|650px]]
<br>
* '''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.
<br>
[[File:Hitissue4.png|650px]]
<br>
* '''Issue 5''' - The code coverage will increase once tests for late_policy.rb and late_policies_controller.rb are written.
<br>
[[File:Hitissue5.png|650px]]
<br>

<br>

===Test Plan===
----
'''''Before fix'''''
<br>
<br>
'''Manual Testing ()'''

#[https://drive.google.com/file/d/1gpW2Y6mw-ctg5EZE4JZoSLS5mjJuIg1S/view?usp=sharing Working Demo Video]

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>

'''''After fix'''''
<br>
<br>

'''Automated Testing Using RSpec'''

We created two new test files, late_policy_spec.rb and late_policies_controller_spec.rb which cover test scenarios for late_policy.rb and late_policies_controller.rb repesctively.

'''late_policy_spec.rb'''

This test suite covers the two functions available in the model. Our test ensures that the model functions as expected. Most of the corner cases are being covered by controller test and thus the key to this test suite is ensuring all functionalities function as expected.

[[File:Test_1.png|600px]]

The first function in the model is for checking if for a particular instructor, the policy name already exists. For this scenario, there are two possible outcomes :
* Policy name already exists under an instructor.
* Policy name does not exists under an instructor.

Our test cases cover both of these scenarios.

[[File:Test_2.png|600px]]
[[File:Test_3.png|600px]]

The second method in this controller checks if penalty points are being updated correctly or not. One key aspect to testing this function was the mocking of the helper method. Our model depends on a helper file to update penalty points based on certain factors. Since the functionality of the model should be independent of helper behavior, we have mocked that call. The calculation of penalty is based on the type of the deadline which can have 4 possible values :
* nil
* 1
* 2
* 5

Based on each none or one of the penalty points from submission, review or meta_review gets updated. Our test suite goes through each and ensures the correct one is being updated.

'''late_policies_controller_spec.rb'''
Our controller test ensures that the controller works as expected. We have covered the test cases for each method present in the controller, Moreover, we tried to cover most of the corner cases. We have total of 14 controller test case and detailed test cases can be checked out in our pull request (#[https://github.com/expertiza/expertiza/pull/2127 Pull Request]).

Following are few test cases :

1.) This test case covers the scenario where the penalty per unit exceeds the max penalty for an assignment.

[[File:MaxPenaltyLess.png]]

2.) Trying to create/update policy which already exists.

[[File:SamePolicy.png]]

[[File:createSamePolicy.png]]

3.) Delete the policy.

[[File:DestroyPolicy.png]]

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

Test coverage has been increased by 0.6 percentage :

[[File:Coverage.png]]

==Milestones==
'''10/25''' – Project Selection

'''11/03''' – Develop Project Design Document

'''11/06''' – Update Project Design Document based on feedback from Round 1

==Project Mentors==
*Tirth Patel

==Team Members==
* Anmol Lunavat

* Shubham Waghe

* Vishal Sharma

==Useful Links==
===E2157===
#[https://github.com/wshubham/expertiza/tree/beta GitHub forked repository]
#[https://github.com/expertiza/expertiza/pull/2127 Pull Request]

===Expertiza===
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ Live Expertiza website]

E2157. Fix issues related to deadlines and late policies

2021-11-30T18:25:54Z

Swaghe:

__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). The team found some issues in the current implementation which either cause errors are completely not functional. The goal of this project is to eliminate these issues by making necessary changes and adding new test cases which cover all scenarios.

====Issues with the Current Implementation====
The following issues have been raised in the current implementation:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”.

[[File:Qissue1.png|650px]]

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

[[File:Qissue2.png|650px]]

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

[[File:Qissue31.png|650px]]

[[File:Qissue32.png|650px]]

* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work.

[[File:Issue41.png|650px]]

[[File:Issue42.png|650px]]

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

====Refactoring and Design Patterns====
Since our goal is to fix existing functionalities we will not be updating the existing design patterns being employed in the code. Yet, we would like to discuss what makes these refactoring important. Refactoring is a systematic process of improving code without creating new functionality. Thus, a key to the success of our project is ensuring everything that was working before our changes work even after our changes have been added. To ensure this, we will continue to test the system after each issue has been fixed. This will allow us to ensure two things:

* We are only changing what we set out to change when fixing a particular issue.
* We are not breaking what was working before we deployed our fix.

We believe at the end our changes will increase the quality of Expertiza and improve the experience for users an developers alike.

==Project Scope==
[[File:Rsz late policy.png|600px]]
<br>
All the issues raised mainly exist in the "Due Dates" tab on the "Edit Assignment" page.
* '''Issue 1''' - Change "penalty policy" to "late policy" on all the relevant UI screens (app/views/late_policies).
* '''Issue 2''' - Analyze and fix required function and write appropriate test cases (late_policies_controller.rb).
* '''Issue 3''' - Analyze and fix required function and write appropriate test cases (late_policies_controller.rb).
* '''Issue 4''' - Analyze and fix required function and write appropriate test cases (late_policies_controller.rb).
* '''Issue 5''' - Write new test cases for late_policies_controller.rb and late_policy.rb.

==Problem description, Approach & Fix==

<h3> Issue 1: Renaming penalty policy to late policy</h3>
'''Problem Description: ''' Usage of different terms for the same thing causes ambiguity and can lead to unfortunate errors. In this instance having two different terms for "late policy" will cause confusion when instructors are creating assignments.

'''Fix:''' To avoid confusion, use “late policy” exclusively.

<h3> Issue 2: Issue 2: Late policies cannot be created without raising an error </h3>
'''Problem Description: ''' The current implementation throws errors whenever late policies are created. Most of these errors are from the end of the system and not users. This is not desirable from our system as it should be able to handle internal errors and throw error messages only when they are absolutely required.

'''Fix:'''
<ul>
<li>Ensure that all errors being raised are fixed. This will be achieved by modifying existing code and bringing new checks as and when required.0</li>
<li>Added a flash error message in the create function of late_policies_controller.rb</li>
</ul>

<h3> Issue 3: After creating a late policy, the “back” link does not take the user back to editing the assignment.</h3>
'''Problem Description: ''' The "back" button functionality is broken. In an extensive system like ours, such issues can make our users irritable and do not provide them with the best user experience. These navigation buttons are an important part of the system and should take the users to correct pages.

'''Fix:''' Ensure that on click of the back button, the user is taken back to the assignment page.

<h3>Issue 4: The "+" and "-" buttons for Show/Hide Date Updater do not work.</h3>
'''Problem Description: ''' If I create an assignment by copying an old assignment, the due dates are copied too. It is likely that I want the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.). To avoid the need to edit all the deadlines manually, Expertiza has a date updater. Currently, the broken "+" and "-" button make it hard for our users to take full advantage of this functionality.

'''Fix:''' Editing the code linked to these button should allow us to ensure that users can increment and decrement between dates as per requirements.

<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>
'''Problem Description: ''' The purpose of a test case is to determine if different features within a system are performing as expected and to confirm that the system satisfies all related standards, guidelines, and customer requirements. The process of writing a test case can also help reveal errors or defects within the system.

'''Fix:'''
<ul>
<li>Add test file for late_policies_controller_spec.rb with appropriate test cases</li>
<li>Add test file for late_policies_spec.rb with appropriate test cases
</ul>

==Expected Results==
We expect the new code changes should not break existing functionality and the following results upon completion:
<br>
* '''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.
<br>
[[File:Hitissue11.png|650px]]
<br>
* '''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.
<br>
[[File:Hitissue2.png|650px]]
<br>
* '''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.
<br>
[[File:Hitissue3.png|650px]]
<br>
* '''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.
<br>
[[File:Hitissue4.png|650px]]
<br>
* '''Issue 5''' - The code coverage will increase once tests for late_policy.rb and late_policies_controller.rb are written.
<br>
[[File:Hitissue5.png|650px]]
<br>

<br>

===Test Plan===
----
'''''Before fix'''''
<br>
<br>
'''Manual Testing ()'''

#[https://drive.google.com/file/d/1gpW2Y6mw-ctg5EZE4JZoSLS5mjJuIg1S/view?usp=sharing Working Demo Video]

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>

'''''After fix'''''
<br>
<br>

'''Automated Testing Using RSpec'''

We created two new test files, late_policy_spec.rb and late_policies_controller_spec.rb which cover test scenarios for late_policy.rb and late_policies_controller.rb repesctively.

'''late_policy_spec.rb'''

This test suite covers the two functions available in the model. Our test ensures that the model functions as expected. Most of the corner cases are being covered by controller test and thus the key to this test suite is ensuring all functionalities function as expected.

[[File:Test_1.png|600px]]

The first function in the model is for checking if for a particular instructor, the policy name already exists. For this scenario, there are two possible outcomes :
* Policy name already exists under an instructor.
* Policy name does not exists under an instructor.

Our test cases cover both of these scenarios.

[[File:Test_2.png|600px]]
[[File:Test_3.png|600px]]

The second method in this controller checks if penalty points are being updated correctly or not. One key aspect to testing this function was the mocking of the helper method. Our model depends on a helper file to update penalty points based on certain factors. Since the functionality of the model should be independent of helper behavior, we have mocked that call. The calculation of penalty is based on the type of the deadline which can have 4 possible values :
* nil
* 1
* 2
* 5

Based on each none or one of the penalty points from submission, review or meta_review gets updated. Our test suite goes through each and ensures the correct one is being updated.

'''late_policies_controller_spec.rb'''
Our controller test ensures that the controller works as expected. We have covered the test cases for each method present in the controller, Moreover, we tried to cover most of the corner cases. We have total of 14 controller test case and detailed test cases can be checked out in our pull request (#[https://github.com/expertiza/expertiza/pull/2127 Pull Request]).

Following are few test cases :

1.) This test case covers the scenario where the penalty per unit exceeds the max penalty for an assignment.

[[File:MaxPenaltyLess.png]]

2.) Trying to create/update policy which already exists.

[[File:SamePolicy.png]]

[[File:createSamePolicy.png]]

3.) Delete the policy.

[[File:DestroyPolicy.png]]

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

Test coverage has been increased by 0.6 percentage :

[[File:Coverage.png]]

==Milestones==
'''10/25''' – Project Selection

'''11/03''' – Develop Project Design Document

'''11/06''' – Update Project Design Document based on feedback from Round 1

==Project Mentors==
*Tirth Patel

==Team Members==
* Anmol Lunavat

* Shubham Waghe

* Vishal Sharma

==Useful Links==
===E2157===
#[https://github.com/wshubham/expertiza/tree/beta GitHub forked repository]
#[https://github.com/expertiza/expertiza/pull/2127 Pull Request]

===Expertiza===
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ Live Expertiza website]

E2157. Fix issues related to deadlines and late policies

2021-11-30T18:21:40Z

Swaghe:

__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). The team found some issues in the current implementation which either cause errors are completely not functional. The goal of this project is to eliminate these issues by making necessary changes and adding new test cases which cover all scenarios.

====Issues with the Current Implementation====
The following issues have been raised in the current implementation:
* '''Issue 1''' - In the UI, the policy is sometimes called a “late policy” and sometimes a “penalty policy”.

[[File:Qissue1.png|650px]]

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

[[File:Qissue2.png|650px]]

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

[[File:Qissue31.png|650px]]

[[File:Qissue32.png|650px]]

* '''Issue 4''' - The "+" and "-" buttons for Show/Hide Date Updater do not work.

[[File:Issue41.png|650px]]

[[File:Issue42.png|650px]]

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

====Refactoring and Design Patterns====
Since our goal is to fix existing functionalities we will not be updating the existing design patterns being employed in the code. Yet, we would like to discuss what makes these refactoring important. Refactoring is a systematic process of improving code without creating new functionality. Thus, a key to the success of our project is ensuring everything that was working before our changes work even after our changes have been added. To ensure this, we will continue to test the system after each issue has been fixed. This will allow us to ensure two things:

* We are only changing what we set out to change when fixing a particular issue.
* We are not breaking what was working before we deployed our fix.

We believe at the end our changes will increase the quality of Expertiza and improve the experience for users an developers alike.

==Project Scope==
[[File:Rsz late policy.png|600px]]
<br>
All the issues raised mainly exist in the "Due Dates" tab on the "Edit Assignment" page.
* '''Issue 1''' - Change "penalty policy" to "late policy" on all the relevant UI screens (app/views/late_policies).
* '''Issue 2''' - Analyze and fix required function and write appropriate test cases (late_policies_controller.rb).
* '''Issue 3''' - Analyze and fix required function and write appropriate test cases (late_policies_controller.rb).
* '''Issue 4''' - Analyze and fix required function and write appropriate test cases (late_policies_controller.rb).
* '''Issue 5''' - Write new test cases for late_policies_controller.rb and late_policy.rb.

==Problem description, Approach & Fix==

<h3> Issue 1: Renaming penalty policy to late policy</h3>
'''Problem Description: ''' Usage of different terms for the same thing causes ambiguity and can lead to unfortunate errors. In this instance having two different terms for "late policy" will cause confusion when instructors are creating assignments.

'''Fix:''' To avoid confusion, use “late policy” exclusively.

<h3> Issue 2: Issue 2: Late policies cannot be created without raising an error </h3>
'''Problem Description: ''' The current implementation throws errors whenever late policies are created. Most of these errors are from the end of the system and not users. This is not desirable from our system as it should be able to handle internal errors and throw error messages only when they are absolutely required.

'''Fix:'''
<ul>
<li>Ensure that all errors being raised are fixed. This will be achieved by modifying existing code and bringing new checks as and when required.0</li>
<li>Added a flash error message in the create function of late_policies_controller.rb</li>
</ul>

<h3> Issue 3: After creating a late policy, the “back” link does not take the user back to editing the assignment.</h3>
'''Problem Description: ''' The "back" button functionality is broken. In an extensive system like ours, such issues can make our users irritable and do not provide them with the best user experience. These navigation buttons are an important part of the system and should take the users to correct pages.

'''Fix:''' Ensure that on click of the back button, the user is taken back to the assignment page.

<h3>Issue 4: The "+" and "-" buttons for Show/Hide Date Updater do not work.</h3>
'''Problem Description: ''' If I create an assignment by copying an old assignment, the due dates are copied too. It is likely that I want the same increment between due dates as in the old assignment (e.g., two days for the review phase, three days for resubmission, etc.). To avoid the need to edit all the deadlines manually, Expertiza has a date updater. Currently, the broken "+" and "-" button make it hard for our users to take full advantage of this functionality.

'''Fix:''' Editing the code linked to these button should allow us to ensure that users can increment and decrement between dates as per requirements.

<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>
'''Problem Description: ''' The purpose of a test case is to determine if different features within a system are performing as expected and to confirm that the system satisfies all related standards, guidelines, and customer requirements. The process of writing a test case can also help reveal errors or defects within the system.

'''Fix:'''
<ul>
<li>Add test file for late_policies_controller_spec.rb with appropriate test cases</li>
<li>Add test file for late_policies_spec.rb with appropriate test cases
</ul>

==Expected Results==
We expect the new code changes should not break existing functionality and the following results upon completion:
<br>
* '''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.
<br>
[[File:Hitissue11.png|650px]]
<br>
* '''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.
<br>
[[File:Hitissue2.png|650px]]
<br>
* '''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.
<br>
[[File:Hitissue3.png|650px]]
<br>
* '''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.
<br>
[[File:Hitissue4.png|650px]]
<br>
* '''Issue 5''' - The code coverage will increase once tests for late_policy.rb and late_policies_controller.rb are written.
<br>
[[File:Hitissue5.png|650px]]
<br>

<br>

===Test Plan===
----
'''''Before fix'''''
<br>
<br>
'''Manual Testing ()'''

#[https://drive.google.com/file/d/1gpW2Y6mw-ctg5EZE4JZoSLS5mjJuIg1S/view?usp=sharing Working Demo Video]

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>

'''''After fix'''''
<br>
<br>

'''Automated Testing Using RSpec'''

We created two new test files, late_policy_spec.rb and late_policies_controller_spec.rb which cover test scenarios for late_policy.rb and late_policies_controller.rb repesctively.

'''late_policy_spec.rb'''

This test suite covers the two functions available in the model. Our test ensures that the model functions as expected. Most of the corner cases are being covered by controller test and thus the key to this test suite is ensuring all functionalities function as expected.

[[File:Test_1.png|600px]]

The first function in the model is for checking if for a particular instructor, the policy name already exists. For this scenario, there are two possible outcomes :
* Policy name already exists under an instructor.
* Policy name does not exists under an instructor.

Our test cases cover both of these scenarios.

[[File:Test_2.png|600px]]
[[File:Test_3.png|600px]]

The second method in this controller checks if penalty points are being updated correctly or not. One key aspect to testing this function was the mocking of the helper method. Our model depends on a helper file to update penalty points based on certain factors. Since the functionality of the model should be independent of helper behavior, we have mocked that call. The calculation of penalty is based on the type of the deadline which can have 4 possible values :
* nil
* 1
* 2
* 5

Based on each none or one of the penalty points from submission, review or meta_review gets updated. Our test suite goes through each and ensures the correct one is being updated.

'''late_policies_controller_spec.rb'''
Our controller test ensures that the controller works as expected. We have covered the test cases for each method present in the controller, Moreover, we tried to cover most of the corner cases. We have total of 14 controller test case and detailed test cases can be checked out in our pull request (#[https://github.com/expertiza/expertiza/pull/2127 Pull Request]).

Following are few test cases :
1.) This test case covers the scenario where the penalty per unit exceeds the max penalty for an assignment.
[[File:MaxPenaltyLess.jpg]]

2.) Trying to create/update policy which already exists.
[[File:SamePolicy.png]]

[[File:createSamePolicy.png]]

3.) Delete the policy.

[[File:DestroyPolicy.png]]

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

Test coverage has been increased by 0.6 percentage :

[[File:Coverage.png]]

==Milestones==
'''10/25''' – Project Selection

'''11/03''' – Develop Project Design Document

'''11/06''' – Update Project Design Document based on feedback from Round 1

==Project Mentors==
*Tirth Patel

==Team Members==
* Anmol Lunavat

* Shubham Waghe

* Vishal Sharma

==Useful Links==
===E2157===
#[https://github.com/wshubham/expertiza/tree/beta GitHub forked repository]
#[https://github.com/expertiza/expertiza/pull/2127 Pull Request]

===Expertiza===
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ Live Expertiza website]

File:Coverage.png

2021-11-30T18:14:19Z

Swaghe:

File:DestroyPolicy.png

2021-11-30T18:09:26Z

Swaghe:

File:CreateSamePolicy.png

2021-11-30T18:07:31Z

Swaghe:

File:SamePolicy.png

2021-11-30T18:04:13Z

Swaghe:

File:MaxPenaltyLess.png

2021-11-30T17:54:09Z

Swaghe:

E2157. Fix issues related to deadlines and late policies

2021-11-03T23:16:49Z

Swaghe:

E2157. Fix issues related to deadlines and late policies

2021-11-02T21:08:56Z

Swaghe:

E2157. Fix issues related to deadlines and late policies

2021-11-02T21:01:41Z

Swaghe:

E2157. Fix issues related to deadlines and late policies

2021-11-02T20:57:31Z

Swaghe:

CSC/ECE 517 Fall 2021 - E2145. OSS Project Beige

2021-10-26T22:04:49Z

Swaghe:

''This has contributions from Anmol Lunavat, Shubham Waghe and Vishal Sharma''

This wiki page provides description of changes made under E2145 OSS assignment for Fall 2021, CSC/ECE 517.

==About Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Problem Statement==
When a participant updates the submission after the reading the review comments, the reviewer will have to review it again when the second review cycle starts. However, since the reviewer may have multiple submissions to review, some of which are updated, and some that are not, it becomes difficult for the reviewer to identify the updated submissions that need attention. Currently there is no way of identifying the difference between updated and stale submissions.

==Proposed Solution==
For identifying the submission status of the project in next review cycle, the reviewer should be able to quickly identify the submissions that need attention. This can be done in the UI of the reviewer’s page. The submissions can be color-coded using a scheme like the one used in the “Review Report” page.
* <span style="color:red">Red</span> – If the review has not been started
* <span style="color:orange">Orange</span> – If the review was started, but not completed
* <span style="color:brown">Brown</span> – Submission has been reviewed

This solution will allows reviewers to identify and prioritize their work without having to dig deep into individual submissions.

[[File:Workflow-Diagram.PNG|600px]]

The following diagram illustrates how the control would flow. As the user acts on a review, the status of the review changes.

==Tasks==
The following would be the key tasks:
* Add a new model to track the status of a review
* Upon change of review stage, update the data in the database.
* Change color in the UI based on the status of the review.

==Implementation==
===List of Changes===
We came up with the following model to capture the status of a review.

[[File:Review Status Map.PNG|1000px]]

We will keep a track of the stage a review is in. The following would be the three stages of a review:
*Ready : As soon as a student requests for a new review.
*Started : Once a student has started the review.
*Completed : Once a review has been submitted.

This will allow us to designate a unique color for each stage and update accordingly.

[[File:Ready.PNG|1000px]]

'''As soon as a review is assigned to a user, create a new entry in the Review Status table with the status of "Ready".'''

[[File:Started.PNG|1000px]]
[[File:Started1.PNG|1000px]]

'''Once a student starts doing the review, we fetch the record from Review Status table and update the status to "Started".'''

[[File:Completed.PNG|1000px]]
[[File:Completed1.PNG|1000px]]

'''Once a review is submitted from student's end we mark the status of the review to be "Completed".'''

==Testing==
Since our code changes were mostly linear, we can rely on existing test cases to cover all edge cases. The key check for us was to ensure a new entry to the Review Status Map is created as soon as a review has been requested.
===Rspec===
[[File:Test_Ready.PNG|600px]]

This basic test checks that a review gets status as "Ready" when the user requests for a new review.

===Capybara Test===

This basic test checks that a review is in "Ready" state and has a red color in UI.

[[File:UI_test_cases.png]]

===Note===
Since we did not add new controllers and are relying on existing implementation to help us update the status of the review, we have not added any other tests. A video of testing has been uploaded and one can follow Manual Testing steps to review/verify the changes.

----

'''Manual Testing'''

Please follow the below steps for manual testing:
*Login using id: instructor6 password: password.
*Navigate to the Assignments tab under Manage.
*Create a new Assignment and assign to the following student ids : student2150, student2151, student2152.
*Navigate to Impersonate User under Manage.
*Impersonate as one of the users at a time and make a dummy submission.
*Once that is done and the stage of the assignment has changed to Review, go to Other's work tab and Request a new submission.
*A new review gets added to page and you should see the color as Red.
*Now click on Begin. Once satisfied click Save and hit back.
*Now you should see the highlighted color change to Orange.
*Once satisfied click View/Edit review and submit it.
*Now you should see the highlighted color change to Brown.

[https://drive.google.com/file/d/1Zx2aBxsuFw28znq_YCoJcO7CImg021Bx/view?usp=sharing Manual Testing Video]

''Please set the deadlines correctly and you should be good. Our code does not control the stages or deadlines and thus you will have to be careful in order to test everything.''

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

File:UI test cases.png

2021-10-26T21:47:11Z

Swaghe:

CSC/ECE 517 Fall 2021 - E2145. OSS Project Beige

2021-10-24T15:57:12Z

Swaghe:

''This has contributions from Anmol Lunavat, Shubham Waghe and Vishal Sharma''

This wiki page provides description of changes made under E2145 OSS assignment for Fall 2021, CSC/ECE 517.

==About Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Problem Statement==
When a participant updates the submission after the reading the review comments, the reviewer will have to review it again when the second review cycle starts. However, since the reviewer may have multiple submissions to review, some of which are updated, and some that are not, it becomes difficult for the reviewer to identify the updated submissions that need attention. Currently there is no way of identifying the difference between updated and stale submissions.

==Proposed Solution==
For identifying the submission status of the project in next review cycle, the reviewer should be able to quickly identify the submissions that need attention. This can be done in the UI of the reviewer’s page. The submissions can be color-coded using a scheme like the one used in the “Review Report” page.
* <span style="color:red">Red</span> – If the review has not been started
* <span style="color:orange">Orange</span> – If the review was started, but not completed
* <span style="color:brown">Brown</span> – Submission has been reviewed

This solution will allows reviewers to identify and prioritize their work without having to dig deep into individual submissions.

[[File:Workflow-Diagram.PNG|600px]]

The following diagram illustrates how the control would flow. As the user acts on a review, the status of the review changes.

==Tasks==
The following would be the key tasks:
* Add a new model to track the status of a review
* Upon change of review stage, update the data in the database.
* Change color in the UI based on the status of the review.

==Implementation==
===List of Changes===
We came up with the following model to capture the status of a review.

[[File:Review Status Map.PNG|1000px]]

We will keep a track of the stage a review is in. The following would be the three stages of a review:
*Ready : As soon as a student requests for a new review.
*Started : Once a student has started the review.
*Completed : Once a review has been submitted.

This will allow us to designate a unique color for each stage and update accordingly.

[[File:Ready.PNG|1000px]]

'''As soon as a review is assigned to a user, create a new entry in the Review Status table with the status of "Ready".'''

[[File:Started.PNG|1000px]]
[[File:Started1.PNG|1000px]]

'''Once a student starts doing the review, we fetch the record from Review Status table and update the status to "Started".'''

[[File:Completed.PNG|1000px]]
[[File:Completed1.PNG|1000px]]

'''Once a review is submitted from student's end we mark the status of the review to be "Completed".'''

==Testing==
Since our code changes were mostly linear, we can rely on existing test cases to cover all edge cases. The key check for us was to ensure a new entry to the Review Status Map is created as soon as a review has been requested.
===Rspec===
[[File:Test_Ready.PNG|600px]]

This basic test checks that a review gets status as "Ready" when the user requests for a new review.

Since we did not add new controllers and are relying on existing implementation to help us update the status of the review, we have not added any other tests. A video of testing has been uploaded and one can follow Manual Testing steps to review/verify the changes.

----

'''Manual Testing'''

Please follow the below steps for manual testing:
*Login using id: instructor6 password: password.
*Navigate to the Assignments tab under Manage.
*Create a new Assignment and assign to the following student ids : student2150, student2151, student2152.
*Navigate to Impersonate User under Manage.
*Impersonate as one of the users at a time and make a dummy submission.
*Once that is done and the stage of the assignment has changed to Review, go to Other's work tab and Request a new submission.
*A new review gets added to page and you should see the color as Red.
*Now click on Begin. Once satisfied click Save and hit back.
*Now you should see the highlighted color change to Orange.
*Once satisfied click View/Edit review and submit it.
*Now you should see the highlighted color change to Brown.

[https://drive.google.com/file/d/1Zx2aBxsuFw28znq_YCoJcO7CImg021Bx/view?usp=sharing Manual Testing Video]

''Please set the deadlines correctly and you should be good. Our code does not control the stages or deadlines and thus you will have to be careful in order to test everything.''

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

CSC/ECE 517 Fall 2021 - E2145. OSS Project Beige

2021-10-24T15:53:53Z

Swaghe:

''This has contributions from Anmol Lunavat, Shubham Waghe and Vishal Sharma''

This wiki page provides description of changes made under E2145 OSS assignment for Fall 2021, CSC/ECE 517.

==About Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Problem Statement==
When a participant updates the submission after the reading the review comments, the reviewer will have to review it again when the second review cycle starts. However, since the reviewer may have multiple submissions to review, some of which are updated, and some that are not, it becomes difficult for the reviewer to identify the updated submissions that need attention. Currently there is no way of identifying the difference between updated and stale submissions.

==Proposed Solution==
For identifying the submission status of the project in next review cycle, the reviewer should be able to quickly identify the submissions that need attention. This can be done in the UI of the reviewer’s page. The submissions can be color-coded using a scheme like the one used in the “Review Report” page.
* <span style="color:red">Red</span> – If the review has not been started
* <span style="color:orange">Orange</span> – If the review was started, but not completed
* <span style="color:brown">Brown</span> – Submission has been reviewed

This solution will allows reviewers to identify and prioritize their work without having to dig deep into individual submissions.

[[File:Workflow-Diagram.PNG|600px]]

The following diagram illustrates how the control would flow. As the user acts on a review, the status of the review changes.

==Tasks==
The following would be the key tasks:
* Add a new model to track the status of a review
* Upon change of review stage, update the data in the database.
* Change color in the UI based on the status of the review.

==Implementation==
===List of Changes===
We came up with the following model to capture the status of a review.

[[File:Review Status Map.PNG|1000px]]

We will keep a track of the stage a review is in. The following would be the three stages of a review:
*Ready : As soon as a student requests for a new review.
*Started : Once a student has started the review.
*Completed : Once a review has been submitted.

This will allow us to designate a unique color for each stage and update accordingly.

[[File:Ready.PNG|1000px]]

'''As soon as a review is assigned to a user, create a new entry in the Review Status table with the status of "Ready".'''

[[File:Started.PNG|1000px]]
[[File:Started1.PNG|1000px]]

'''Once a student starts doing the review, we fetch the record from Review Status table and update the status to "Started".'''

[[File:Completed.PNG|1000px]]
[[File:Completed1.PNG|1000px]]

'''Once a review is submitted from student's end we mark the status of the review to be "Completed".'''

==Testing==
Since our code changes were mostly linear, we can rely on existing test cases to cover all edge cases. The key check for us was to ensure a new entry to the Review Status Map is created as soon as a review has been requested.
===Rspec===
[[File:Test_Ready.PNG|600px]]

This basic test checks that a review gets status as "Ready" when the user requests for a new review.

Since we did not add new controllers and are relying on existing implementation to help us update the status of the review, we have not added any other tests. A video of testing has been uploaded and one can follow Manual Testing steps to review/verify the changes.

----

'''Manual Testing'''

Please follow the below steps for manual testing:
*Login using id: instructor6 password: password.
*Navigate to the Assignments tab under Manage.
*Create a new Assignment and assign to the following student ids : student2150, student2151, student2152.
*Navigate to Impersonate User under Manage.
*Impersonate as one of the users at a time and make a dummy submission.
*Once that is done and the stage of the assignment has changed to Review, go to Other's work tab and Request a new submission.
*A new review gets added to page and you should see the color as Red.
*Now click on Begin. Once satisfied click Save and hit back.
*Now you should see the highlighted color change to Orange.
*Once satisfied click View/Edit review and submit it.
*Now you should see the highlighted color change to Brown.

#[https://drive.google.com/file/d/1Zx2aBxsuFw28znq_YCoJcO7CImg021Bx/view?usp=sharing Manual Testing Video]

''Please set the deadlines correctly and you should be good. Our code does not control the stages or deadlines and thus you will have to be careful in order to test everything.''

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

E2145. OSS Project Beige

2021-10-20T21:55:53Z

Swaghe: /* UI Testing */

This wiki page provides description of changes made under E2145 OSS assignment for Fall 2021, CSC/ECE 517.

==About Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Problem Statement==
When a participant updates the submission after the reading the review comments, the reviewer will have to review it again when the second review cycle starts. However, since the reviewer may have multiple submissions to review, some of which are updated, and some that are not, it becomes difficult for the reviewer to identify the updated submissions that need attention. Currently there is no way of identifying the difference between updated and stale submissions.

==Proposed Solution==
For identifying the submission status of the project in next review cycle, the reviewer should be able to quickly identify the submissions that need attention. This can be done in the UI of the reviewer’s page. The submissions can be color-coded using a scheme like the one used in the “Review Report” page.
* <span style="color:red">Red</span> – If the review has not been started
* <span style="color:orange">Orange</span> – If the review was started, but not completed
* <span style="color:brown">Brown</span> – Submission has been reviewed

This solution will allows reviewers to identify and prioritize their work without having to dig deep into individual submissions.

[[File:Workflow-Diagram.PNG|600px]]

The following diagram illustrates how the control would flow. As the user acts on a review, the status of the review changes.

==Tasks==
The following would be the key tasks:
* Add a new model to track the status of a review
* Upon change of review stage, update the data in the database.
* Change color in the UI based on the status of the review.

==Implementation==
===List of Changes===
We came up with the following model to capture the status of a review.
[[File:Review Status Map.PNG|1000px]]

We will keep of the stage a review is in. The following would be the three stages of a review:
*Ready : As soon as a student requests for a new review.
*Started : Once a student has started the review.
*Completed : Once a review has been submitted.

This will allow us to designate a unique color to each stage and update accordingly.

[[File:Ready.PNG|1000px]]

'''As soon as a review is assigned to a user, create a new entry in the Review Status table with the status of "Ready".'''

[[File:Started.PNG|1000px]]
[[File:Started1.PNG|1000px]]

'''Once a student starts doing the review, we fetch the record from Review Status table and update the status to "Started".'''

[[File:Completed.PNG|1000px]]
[[File:Completed1.PNG|1000px]]

'''Once a review is submitted from student's end we mark the status of the review to be "Completed".'''

==Testing==
===Rspec===
[[File:Test_Ready.PNG|600px]]

This basic test checks that a review gets status as "Ready" when the user requests for a new review.

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