Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2024 - E2486.Reimplement deadline rights and deadline types

2024-12-04T05:09:08Z

Pechopel:

=Project 4 Design Doc=
==Issues==
1. '''Determining Late Submissions:'''
* There is a need to calculate whether submissions or reviews are late based on the due dates.
* '''Issue:''' The current system does not have a straightforward way to identify late submissions or track submission dates easily.

2. '''Handling Late Team Formation:'''
* Teams that form after the due date should incur a penalty.
* '''Issue:''' Team formation dates may not be explicitly tracked in the current system, or if they are, they are not used for penalty calculation.

3. '''Handling Review Penalties:'''
* Participants who fail to complete reviews on time should incur a penalty as well.
* '''Issue:''' Reviews are often tied to the response maps or individual participants, so there's a challenge in ensuring penalties are applied consistently across different models.

4. '''Penalty Application:'''
* The penalty calculation should be easily extensible, and transparent for debugging.
* '''Issue:''' Penalties may need to be applied in multiple places within the codebase, but should be kept modular and readable.

5. '''Code Maintainability and Readability:'''
* The code should remain maintainable as penalties could apply to more parts of the application in the future.
* '''Issue:''' Repeating penalty logic across models may lead to code duplication, increasing maintenance cost.

==Proposed Solutions==
A. '''Introduction of a PenaltyCalculator Mixin'''
* '''Solution:''' A new module `PenaltyCalculator` will be created to handle the penalty calculations. This module will contain methods for calculating submission, review, and team formation penalties.
* '''Benefit:''' It makes the penalty calculation logic reusable, keeps the code DRY, and ensures the logic is centralized.

B. '''Tracking Submission Dates'''
* '''Solution:''' Ensure that submission dates are explicitly tracked in the `Submission` model. Add a method to check if a submission is late based on the due date.
* '''Benefit:''' Provides a straightforward way to identify late submissions and apply penalties accordingly.

C. '''Tracking Team Formation Dates'''
* '''Solution:''' Use the team formation date in the `Team` model to track when a team is formed. Use this date to calculate penalties for late team formation.
* '''Benefit:''' Ensures that penalties for late team formation are applied consistently and accurately.

D. '''Handling Review Penalties'''
* '''Solution:''' Extend the `PenaltyCalculator` mixin to include methods for calculating penalties for late reviews. Ensure that review deadlines are tracked and used in penalty calculations.
* '''Benefit:''' Ensures that penalties for late reviews are applied consistently across different models.

E. '''Extensible Penalty Application'''
* '''Solution:''' Design the `PenaltyCalculator` mixin to be easily extensible, allowing new types of penalties to be added in the future. Use clear and transparent methods for debugging.
* '''Benefit:''' Keeps the penalty calculation logic modular and readable, making it easier to maintain and extend.

F. '''Code Maintainability and Readability'''
* '''Solution:''' Centralize the penalty calculation logic in the `PenaltyCalculator` mixin to avoid code duplication. Ensure that the mixin is included in relevant models where penalties need to be applied.
* '''Benefit:''' Reduces code duplication, making the codebase easier to maintain and ensuring that penalty logic is consistent across the application.

==UML Diagram==
[[File:PenaltyMixinUML.JPG]]

==Implementation of PenaltyCalculator Module==
module PenaltyCalculator
def calculate_penalty(submission_date, due_date, penalty_rate)
return 0 if submission_date <= due_date
days_late = (submission_date.to_date - due_date.to_date).to_i
penalty = days_late * penalty_rate
penalty
end
end

==Summary of Proposed File Changes==

* app/lib/penalty_calculator.rb (new file)
* app/models/assignment.rb (modify to include mixin and penalty calculation method)
* app/models/submission.rb (modify to include mixin and penalty calculation method)
* app/models/participant.rb (modify to include mixin and penalty calculation method)
* app/models/team.rb (modify to include mixin and penalty calculation method)
* config/application.rb (modify to ensure lib directory is autoloaded)
* spec/lib/penalty_calculator_spec.rb (new file for unit tests)
* spec/models/assignment_spec.rb (modify to include tests for penalty calculation)
* spec/models/submission_spec.rb (modify to include tests for penalty calculation)
* spec/models/participant_spec.rb (modify to include tests for penalty calculation)
* spec/models/team_spec.rb (modify to include tests for penalty calculation)

=Final Implementation=
==Resolving Issues==
1. '''Determining Late Submissions''' && 
2. '''Handling Late Team Formation''' && 
3. '''Handling Review Penalties'''
* Our solution simplifies the different types of penalties and enables a single type of penalty to be used for all applications.
* '''Solution:''' Update calculate_penalty in late_policy.rb to determine penalty units and calculate total penalty
<pre>
def calculate_penalty(submission_time, due_date)
return 0 if submission_time <= due_date

time_diff = submission_time - due_date
penalty_units = case penalty_unit
when 'Minute'
time_diff / 60
when 'Hour'
time_diff / 3600
when 'Day'
time_diff / 86400
else
raise 'Invalid penalty unit'
end

raise 'Penalty per unit is missing' if penalty_per_unit.nil?
penalty = penalty_units * penalty_per_unit
[penalty, max_penalty].min.round(2)
end
</pre>

4. '''Penalty Application:'''
* '''Solution:''' Include ScoreCalculationHelper mixin in response.rb and update aggregate_questionnaire_score to calculate and apply penalty to score
<pre>
class Response < ApplicationRecord
include ScoreCalculationHelper
</pre>

<pre>
def aggregate_questionnaire_score
# only count the scorable questions, only when the answer is not nil
# we accept nil as answer for scorable questions, and they will not be counted towards the total score
sum = 0
scores.each do |s|
question = Question.find(s.question_id)
# For quiz responses, the weights will be 1 or 0, depending on if correct
sum += s.answer * question.weight unless s.answer.nil? || !question.is_a?(ScoredQuestion)
end
sum
penalty = LatePolicy.calculate_penalty(submission_time, due_date)
apply_penalty(sum, penalty)
end
</pre>

5. '''Code Maintainability and Readability:'''
* '''Solution:''' Maintaining penalty calculation and application in its own module ensures readability and limits potential for duplicate code elsewhere in the codebase

==Implementation of PenaltyCalculator Module==
module ScoreCalculationHelper
def weighted_score(scores, weights)
total_weight = weights.sum
# Multiply each score by its weight, then divide by the total weight
weighted_scores = scores.zip(weights).map { |score, weight| score * weight }
weighted_scores.sum / total_weight
end
def apply_penalty(score, penalty)
score - (score * penalty / 100.0)
end
end

==Design Patterns and Principles==
While not an explicit implementation, our extension of LatePolicy logic adhered to the Decorator pattern by extending penalty behaviors and adding new parameters like penalty_per_unit and max_penalty. Additonally, we were able to harness the Open/Closed principle in both LatePolicy and DeadlineType by those classes allowing us to create new penalty units (Minutes/Hours/Days) and new types of deadlines for bidding for topics and reviews. Another example of a classic foundational principle, encapsulation, can be found in our implementation of calculate_penalty. Allowing the LatePolicy to do the calculation keeps the logic for the penalties separate from the response and any other classes that might use late policies.

==Test Cases==
Testing is primarily centered around score_calculation_helper.rb with some additional testing in late_policy.rb due to its close ties with penalty enforcement. Other adjustments include stubbing DueDates to ensure the DueDate object returns the proper due_at for your tests:

<code>allow(DueDate).to receive(:find_by).and_return(double('DueDate', due_at: due_date))</code>

Some benefits to stubbing DueDate this way:
*'''Consistency:''' The due_date object is now controlled, avoiding reliance on any database or external factors.
*'''Flexibility:''' You can easily modify the due_date within each test case.
* Isolates the behavior of LatePolicy from database interactions.
* Makes tests faster and more predictable.
* Focuses solely on the calculate_penalty logic

Stubbing example:
<pre>
describe '#calculate_penalty' do
let(:late_policy) { LatePolicy.new(penalty_unit: 'InvalidUnit', penalty_per_unit: 10, max_penalty: 100) }
let(:due_date) { Time.now }
before do
# Stub the due_date object with the desired behavior
allow(DueDate).to receive(:find_by).and_return(double('DueDate', due_at: due_date))
end
it 'raises an error if the penalty unit is invalid' do
submission_time = Time.now + 1.hour
# Expecting an error due to invalid penalty unit
expect { late_policy.calculate_penalty(submission_time, due_date) }.to raise_error('Invalid. Penalty unit must be Minute, Hour or Day')
end
end
</pre>

As our helper is tasked only with computing and applying penalties, our testing revolved primarily around ensuring scoring is correct after penalties are applied.

Example score_calculation_helper.rb test for computation:
<pre>
describe '#apply_penalty' do
it 'reduces the score by the correct percentage penalty' do
score = 100
penalty = 20
expect(apply_penalty(score, penalty)).to eq(80.0)
end
end
</pre>

Example test for handling negative numbers:
<pre>
describe '#apply_penalty' do
it 'raises an error if penalty is negative' do
score = 100
penalty = -20
expect { apply_penalty(score, penalty) }.to raise_error(ArgumentError)
end
end
</pre>

Late policies add in a small additional layer of complexity by seeing how late a submission is and using that to determine the penalty that should be applied.

Example late_policy_spec.rb test for applying a max penalty:
<pre>
describe '#calculate_penalty' do
it 'returns the max penalty when calculated penalty exceeds max_penalty' do
submission_time = Time.now + 10.days
due_date = Time.now
late_policy = LatePolicy.new(penalty_unit: 'Day', penalty_per_unit: 20, max_penalty: 50)
# Time difference is 10 days, calculated penalty would be 10 * 20 = 200
# But since the max penalty is 50, it should return 50
expect(late_policy.calculate_penalty(submission_time, due_date)).to eq(50)
end
end
</pre>

CSC/ECE 517 Fall 2024 - E2486.Reimplement deadline rights and deadline types

2024-12-04T03:47:42Z

Pechopel:

=Project 4 Design Doc=
==Issues==
1. '''Determining Late Submissions:'''
* There is a need to calculate whether submissions or reviews are late based on the due dates.
* '''Issue:''' The current system does not have a straightforward way to identify late submissions or track submission dates easily.

2. '''Handling Late Team Formation:'''
* Teams that form after the due date should incur a penalty.
* '''Issue:''' Team formation dates may not be explicitly tracked in the current system, or if they are, they are not used for penalty calculation.

3. '''Handling Review Penalties:'''
* Participants who fail to complete reviews on time should incur a penalty as well.
* '''Issue:''' Reviews are often tied to the response maps or individual participants, so there's a challenge in ensuring penalties are applied consistently across different models.

4. '''Penalty Application:'''
* The penalty calculation should be easily extensible, and transparent for debugging.
* '''Issue:''' Penalties may need to be applied in multiple places within the codebase, but should be kept modular and readable.

5. '''Code Maintainability and Readability:'''
* The code should remain maintainable as penalties could apply to more parts of the application in the future.
* '''Issue:''' Repeating penalty logic across models may lead to code duplication, increasing maintenance cost.

==Proposed Solutions==
A. '''Introduction of a PenaltyCalculator Mixin'''
* '''Solution:''' A new module `PenaltyCalculator` will be created to handle the penalty calculations. This module will contain methods for calculating submission, review, and team formation penalties.
* '''Benefit:''' It makes the penalty calculation logic reusable, keeps the code DRY, and ensures the logic is centralized.

B. '''Tracking Submission Dates'''
* '''Solution:''' Ensure that submission dates are explicitly tracked in the `Submission` model. Add a method to check if a submission is late based on the due date.
* '''Benefit:''' Provides a straightforward way to identify late submissions and apply penalties accordingly.

C. '''Tracking Team Formation Dates'''
* '''Solution:''' Use the team formation date in the `Team` model to track when a team is formed. Use this date to calculate penalties for late team formation.
* '''Benefit:''' Ensures that penalties for late team formation are applied consistently and accurately.

D. '''Handling Review Penalties'''
* '''Solution:''' Extend the `PenaltyCalculator` mixin to include methods for calculating penalties for late reviews. Ensure that review deadlines are tracked and used in penalty calculations.
* '''Benefit:''' Ensures that penalties for late reviews are applied consistently across different models.

E. '''Extensible Penalty Application'''
* '''Solution:''' Design the `PenaltyCalculator` mixin to be easily extensible, allowing new types of penalties to be added in the future. Use clear and transparent methods for debugging.
* '''Benefit:''' Keeps the penalty calculation logic modular and readable, making it easier to maintain and extend.

F. '''Code Maintainability and Readability'''
* '''Solution:''' Centralize the penalty calculation logic in the `PenaltyCalculator` mixin to avoid code duplication. Ensure that the mixin is included in relevant models where penalties need to be applied.
* '''Benefit:''' Reduces code duplication, making the codebase easier to maintain and ensuring that penalty logic is consistent across the application.

==UML Diagram==
[[File:PenaltyMixinUML.JPG]]

==Implementation of PenaltyCalculator Module==
module PenaltyCalculator
def calculate_penalty(submission_date, due_date, penalty_rate)
return 0 if submission_date <= due_date
days_late = (submission_date.to_date - due_date.to_date).to_i
penalty = days_late * penalty_rate
penalty
end
end

==Summary of Proposed File Changes==

* app/lib/penalty_calculator.rb (new file)
* app/models/assignment.rb (modify to include mixin and penalty calculation method)
* app/models/submission.rb (modify to include mixin and penalty calculation method)
* app/models/participant.rb (modify to include mixin and penalty calculation method)
* app/models/team.rb (modify to include mixin and penalty calculation method)
* config/application.rb (modify to ensure lib directory is autoloaded)
* spec/lib/penalty_calculator_spec.rb (new file for unit tests)
* spec/models/assignment_spec.rb (modify to include tests for penalty calculation)
* spec/models/submission_spec.rb (modify to include tests for penalty calculation)
* spec/models/participant_spec.rb (modify to include tests for penalty calculation)
* spec/models/team_spec.rb (modify to include tests for penalty calculation)

=Final Implementation=
==Resolving Issues==
1. '''Determining Late Submissions''' && 
2. '''Handling Late Team Formation''' && 
3. '''Handling Review Penalties'''
* Our solution simplifies the different types of penalties and enables a single type of penalty to be used for all applications.
* '''Solution:''' Update calculate_penalty in late_policy.rb to determine penalty units and calculate total penalty
<pre>
def calculate_penalty(submission_time, due_date)
return 0 if submission_time <= due_date

time_diff = submission_time - due_date
penalty_units = case penalty_unit
when 'Minute'
time_diff / 60
when 'Hour'
time_diff / 3600
when 'Day'
time_diff / 86400
else
raise 'Invalid penalty unit'
end

raise 'Penalty per unit is missing' if penalty_per_unit.nil?
penalty = penalty_units * penalty_per_unit
[penalty, max_penalty].min.round(2)
end
</pre>

4. '''Penalty Application:'''
* '''Solution:''' Include ScoreCalculationHelper mixin in response.rb and update aggregate_questionnaire_score to calculate and apply penalty to score
<pre>
class Response < ApplicationRecord
include ScoreCalculationHelper
</pre>

<pre>
def aggregate_questionnaire_score
# only count the scorable questions, only when the answer is not nil
# we accept nil as answer for scorable questions, and they will not be counted towards the total score
sum = 0
scores.each do |s|
question = Question.find(s.question_id)
# For quiz responses, the weights will be 1 or 0, depending on if correct
sum += s.answer * question.weight unless s.answer.nil? || !question.is_a?(ScoredQuestion)
end
sum
penalty = LatePolicy.calculate_penalty(submission_time, due_date)
apply_penalty(sum, penalty)
end
</pre>

5. '''Code Maintainability and Readability:'''
* '''Solution:''' Maintaining penalty calculation and application in its own module ensures readability and limits potential for duplicate code elsewhere in the codebase

==Implementation of PenaltyCalculator Module==
module ScoreCalculationHelper
def weighted_score(scores, weights)
total_weight = weights.sum
# Multiply each score by its weight, then divide by the total weight
weighted_scores = scores.zip(weights).map { |score, weight| score * weight }
weighted_scores.sum / total_weight
end
def apply_penalty(score, penalty)
score - (score * penalty / 100.0)
end
end``

==Test Cases==
Testing is primarily centered around score_calculation_helper.rb with some additional testing in late_policy.rb due to its close ties with penalty enforcement. Other adjustments include stubbing DueDates to ensure the DueDate object returns the proper due_at for your tests:

<code>allow(DueDate).to receive(:find_by).and_return(double('DueDate', due_at: due_date))</code>

Some benefits to stubbing DueDate this way:
*'''Consistency:''' The due_date object is now controlled, avoiding reliance on any database or external factors.
*'''Flexibility:''' You can easily modify the due_date within each test case.
* Isolates the behavior of LatePolicy from database interactions.
* Makes tests faster and more predictable.
* Focuses solely on the calculate_penalty logic

Stubbing example:
<pre>
describe '#calculate_penalty' do
let(:late_policy) { LatePolicy.new(penalty_unit: 'InvalidUnit', penalty_per_unit: 10, max_penalty: 100) }
let(:due_date) { Time.now }
before do
# Stub the due_date object with the desired behavior
allow(DueDate).to receive(:find_by).and_return(double('DueDate', due_at: due_date))
end
it 'raises an error if the penalty unit is invalid' do
submission_time = Time.now + 1.hour
# Expecting an error due to invalid penalty unit
expect { late_policy.calculate_penalty(submission_time, due_date) }.to raise_error('Invalid. Penalty unit must be Minute, Hour or Day')
end
end
</pre>

As our helper is tasked only with computing and applying penalties, our testing revolved primarily around ensuring scoring is correct after penalties are applied.

Example score_calculation_helper.rb test for computation:
<pre>
describe '#apply_penalty' do
it 'reduces the score by the correct percentage penalty' do
score = 100
penalty = 20
expect(apply_penalty(score, penalty)).to eq(80.0)
end
end
</pre>

Example test for handling negative numbers:
<pre>
describe '#apply_penalty' do
it 'raises an error if penalty is negative' do
score = 100
penalty = -20
expect { apply_penalty(score, penalty) }.to raise_error(ArgumentError)
end
end
</pre>

Late policies add in a small additional layer of complexity by seeing how late a submission is and using that to determine the penalty that should be applied.

Example late_policy_spec.rb test for applying a max penalty:
<pre>
describe '#calculate_penalty' do
it 'returns the max penalty when calculated penalty exceeds max_penalty' do
submission_time = Time.now + 10.days
due_date = Time.now
late_policy = LatePolicy.new(penalty_unit: 'Day', penalty_per_unit: 20, max_penalty: 50)
# Time difference is 10 days, calculated penalty would be 10 * 20 = 200
# But since the max penalty is 50, it should return 50
expect(late_policy.calculate_penalty(submission_time, due_date)).to eq(50)
end
end
</pre>

CSC/ECE 517 Fall 2024 - E2486.Reimplement deadline rights and deadline types

2024-12-04T00:05:30Z

Pechopel:

CSC/ECE 517 Fall 2024 - E2468. Reimplement due date

2024-11-15T01:56:54Z

Pechopel:

CSC/ECE 517 Fall 2024 - E2468. Reimplement due date

2024-11-15T01:56:44Z

Pechopel:

CSC/ECE 517 Fall 2024

2024-11-15T01:54:10Z

Pechopel:

* [[CSC/ECE 517 Fall 2024 - E2450. Refactor assignments_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2451. Reimplement feedback_response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - E2452. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2453. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2024 - E2454. Refactor student_task.rb]]
* [[CSC/ECE 517 Fall 2024 - E2455. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb (Phase 2 - Design Document)]]
* [[CSC/ECE 517 Fall 2024 - E2457. GitHub metrics integration]]
* [[CSC/ECE 517 Fall 2024 - E2458. User management and users table]]
* [[CSC/ECE 517 Fall 2024 - E2459. View for results of bidding]]
* [[CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management]]
* [[CSC/ECE 517 Fall 2024 - E2461. UI for Courses]]
* [[CSC/ECE 517 Fall 2024 - E2461. UI and Backend for Courses]]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2462._UI_for_Questionnaires CSC/ECE 517 Fall 2024 - E2462. UI for Questionnaire.rb]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2463_Implement_Front_End_for_Student_Task_List CSC/ECE 517 Fall 2024 - E2463. UI for Student Task List]
* [[CSC/ECE 517 Fall 2024 - E2464 UI for Project Topics (was: Sign_up_Topics)]]
* [[CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification]]
* [[CSC/ECE 517 Fall 2024 - E2466. UI for Impersonate User]]
* [[CSC/ECE 517 Fall 2024 - E2467. UI for View Submissions]]
* [[CSC/ECE 517 Fall 2024 - E2468. Reimplement due_date]]
* [[CSC/ECE 517 Fall 2024 - E2469. Reimplement grades/view_team]]
* [[CSC/ECE 517 Fall 2024 - E2470. Reimplement grades_controller]]
* [[CSC/ECE 517 Fall 2024 - E2471. Reimplement logger]]
* [[CSC/ECE 517 Fall 2024 - E2472. Reimplement responses_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2473. Reimplement sign up topic.rb as project topic.rb]]
* [[CSC/ECE 517 Fall 2024 - E2474. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2475. Reimplement student_task view]]
* [[CSC/ECE 517 Fall 2024 - E2476. Reimplement student_teams_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2477. Reimplement suggestion_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2478. Reimplement the Question hierarchy as Item hierarchy]]
* [[CSC/ECE 517 Fall 2024 - E2479. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2480. Implement testing for new Bookmarks Controller]]
* [[CSC/ECE 517 Fall 2024 - E2481 Reimplement response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - E2482. Reimplement heatgrid for reviews]]
* [[CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model]]
* [[CSC/ECE 517 Fall 2024 - E2484. Reimplement participants_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2485. Allow reviewers to bid on what to review]]
* [[CSC/ECE 517 Fall 2024 - E2486.Reimplement deadline_rights and deadline_types]]
* [[CSC/ECE 517 Fall 2024 - E2487. Reimplement authorization_helper.rb]]
* [[CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course]]
* [[CSC/ECE 517 Fall 2024 - E2489. Create a UI for Assignment Edit page "Etc" tab in ReactJS]]
* [[CSC/ECE 517 Fall 2024 - E2491.UI for View assignments in Courses view]]
* [[CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Fall 2024 - E2493. UI for Assign Reviewers]]
* [[CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment]]
* [[CSC/ECE 517 Fall 2024 - G2401 Refactor Graphql API endpoint for contribution metrics]]
* [[CSC/ECE 517 Fall 2024 - G2402 Refactor Graphql API endpoint for repositories]]

CSC/ECE 517 Fall 2024

2024-11-15T01:53:42Z

Pechopel:

* [[CSC/ECE 517 Fall 2024 - E2450. Refactor assignments_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2451. Reimplement feedback_response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - E2452. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2453. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2024 - E2454. Refactor student_task.rb]]
* [[CSC/ECE 517 Fall 2024 - E2455. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb (Phase 2 - Design Document)]]
* [[CSC/ECE 517 Fall 2024 - E2457. GitHub metrics integration]]
* [[CSC/ECE 517 Fall 2024 - E2458. User management and users table]]
* [[CSC/ECE 517 Fall 2024 - E2459. View for results of bidding]]
* [[CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management]]
* [[CSC/ECE 517 Fall 2024 - E2461. UI for Courses]]
* [[CSC/ECE 517 Fall 2024 - E2461. UI and Backend for Courses]]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2462._UI_for_Questionnaires CSC/ECE 517 Fall 2024 - E2462. UI for Questionnaire.rb]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2463_Implement_Front_End_for_Student_Task_List CSC/ECE 517 Fall 2024 - E2463. UI for Student Task List]
* [[CSC/ECE 517 Fall 2024 - E2464 UI for Project Topics (was: Sign_up_Topics)]]
* [[CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification]]
* [[CSC/ECE 517 Fall 2024 - E2466. UI for Impersonate User]]
* [[CSC/ECE 517 Fall 2024 - E2467. UI for View Submissions]]
* [[CSC/ECE 517 Fall 2024 - E2468. Reimplement due_date]]
* [[CSC/ECE 517 Fall 2024 - E2469. Reimplement grades/view_team]]
* [[CSC/ECE 517 Fall 2024 - E2470. Reimplement grades_controller]]
* [[CSC/ECE 517 Fall 2024 - E2471. Reimplement logger]]
* [[CSC/ECE 517 Fall 2024 - E2472. Reimplement responses_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2473. Reimplement sign up topic.rb as project topic.rb]]
* [[CSC/ECE 517 Fall 2024 - E2474. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2475. Reimplement student_task view]]
* [[CSC/ECE 517 Fall 2024 - E2476. Reimplement student_teams_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2477. Reimplement suggestion_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2478. Reimplement the Question hierarchy as Item hierarchy]]
* [[CSC/ECE 517 Fall 2024 - E2479. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2480. Implement testing for new Bookmarks Controller]]
* [[CSC/ECE 517 Fall 2024 - E2481 Reimplement response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - E2482. Reimplement heatgrid for reviews]]
* [[CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model]]
* [[CSC/ECE 517 Fall 2024 - E2484. Reimplement participants_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2485. Allow reviewers to bid on what to review]]
* [[CSC/ECE 517 Fall 2024 - E2486. Reimplement deadline_rights and deadline_types]]
* [[CSC/ECE 517 Fall 2024 - E2487. Reimplement authorization_helper.rb]]
* [[CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course]]
* [[CSC/ECE 517 Fall 2024 - E2489. Create a UI for Assignment Edit page "Etc" tab in ReactJS]]
* [[CSC/ECE 517 Fall 2024 - E2491.UI for View assignments in Courses view]]
* [[CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Fall 2024 - E2493. UI for Assign Reviewers]]
* [[CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment]]
* [[CSC/ECE 517 Fall 2024 - G2401 Refactor Graphql API endpoint for contribution metrics]]
* [[CSC/ECE 517 Fall 2024 - G2402 Refactor Graphql API endpoint for repositories]]

CSC/ECE 517 Fall 2024 - E2486.Reimplement deadline rights and deadline types

2024-11-15T01:49:29Z

Pechopel: Created page with "=Project 4 Design Doc= ==Issues== 1. '''Determining Late Submissions:''' * There is a need to calculate whether submissions or reviews are late based on the due dates. * '''Issue:''' The current system does not have a straightforward way to identify late submissions or track submission dates easily. 2. '''Handling Late Team Formation:''' * Teams that form after the due date should incur a penalty. * '''Issue:''' Team formation dates may not be explicitly tracked in the..."

CSC/ECE 517 Fall 2024 - E2468. Reimplement due date

2024-11-13T05:02:53Z

Pechopel: /* UML Diagram */

=About Expertiza=
Expertiza is an open-source project built using Ruby on Rails. It provides a platform for instructors and students to manage, submit, and evaluate assignments and projects. Instructors can create, edit, and grade assignments, while students can collaborate in teams, submit their work, and review peers' submissions. Expertiza supports submission across various document types, including URLs and wiki pages.

=Issues with previous Functionality=
* Outdated Code: The original implementation seems to be very old code that does not utilize features that are standard in current ruby versions. Updating this code improves maintainability and code clarity. A prime example is the use of a flag attribute, which apparently has not been used in nearly a decade.
* Readability: The original due_date.rb had become quite bloated and messy, with overly complex methods that were difficult to read. An example of this is self.get_next_due_date. This could hamper future development as understanding exactly what due dates can and cannot do could become difficult due to unclear code.
* Single-Responsibility Principle Violations: The original implementation violated several SOLID principles, primarily violations around the Single-Responsibility Principle. These issues create difficulty in maintainability as code may need to be updated in multiple places that each do the same thing.

=Design Goals=
* We had one overarching goal with this reimplementation: clean up the old bloated model. To do so, we broke down functionality into two separate buckets - code that was overly complex and/or wordy, which could be reused after some basic cleanup and simplification; and code that was obsolete and therefore could be removed entirely with the reimplementation
* Some attributes of the old model were determined to not be reused in the new implementation. However, these attributes need to be present for backward compatibility, so we removed any references to them but left their associated column within our table.
*

=Implementation=

==Reimplemented Methods==

DueDate

While most of the methods in the original model were functionally correct, we saw areas of possible improvement both in readability and complexity. We also removed a few methods that were unnecessary after reimplementation.

{| class="wikitable" style="width: 100%;
! Reimplemented method !! Description
|-
| due_at_is_valid_datetime || Simple validation that due_at is a datetime and not some other data type.
|-
| self.sort_due_dates || Sorts the due dates by earliest to latest.
|-
| self.fetch_due_dates || Fetches all the due dates for the assignment or topic, then returns the sorted list of due dates.
|-
| self.any_future_due_dates? || Method that returns a boolean of whether there are any upcoming due dates left in the assignment or topic.
|-
| self.next_due_date || Calls the fetcher to retrieve all the due dates for an assignment, then returns the next upcoming due date.
|-
| set || Instance method used to update a due date's deadline type, assignment, and round.
|-
| copy || Instance method to copy all the due dates from one assignment or topic to another.
|}

TopicDueDate

{| class="wikitable" style="width: 100%;
! Reimplemented method !! Description
|-
| self.next_due_date || Overloaded super method to first look for any upcoming topic due dates, and return the next one if so. If there are not any, it returns the next due date for the topic's assignment instead.
|}

== Other changes ==

We did not reimplement these methods as they were unused and therefore obsolete
{| class="wikitable" style="width: 100%;
! Obsolete method !! Description
|-
|self.teammate_review_allowed || Unnecessary method now that teammate_review_allowed is an attr_accessor
|-
|self.done_in_assignment_round || This determined the round that the due date was used in. Unnecessary as we can just grab the deadline_type_id directly from a due_date instance.
|-
|set_flag || Simple setter of the flag attribute. Not reimplemented as flag had not been used since 2015 and no one was really sure what it was used for.
|}

=Project 4 Design Doc=
==Issues==
1. '''Determining Late Submissions:'''
* There is a need to calculate whether submissions or reviews are late based on the due dates.
* '''Issue:''' The current system does not have a straightforward way to identify late submissions or track submission dates easily.

2. '''Handling Late Team Formation:'''
* Teams that form after the due date should incur a penalty.
* '''Issue:''' Team formation dates may not be explicitly tracked in the current system, or if they are, they are not used for penalty calculation.

3. '''Handling Review Penalties:'''
* Participants who fail to complete reviews on time should incur a penalty as well.
* '''Issue:''' Reviews are often tied to the response maps or individual participants, so there's a challenge in ensuring penalties are applied consistently across different models.

4. '''Penalty Application:'''
* The penalty calculation should be easily extensible, and transparent for debugging.
* '''Issue:''' Penalties may need to be applied in multiple places within the codebase, but should be kept modular and readable.

5. '''Code Maintainability and Readability:'''
* The code should remain maintainable as penalties could apply to more parts of the application in the future.
* '''Issue:''' Repeating penalty logic across models may lead to code duplication, increasing maintenance cost.

==Proposed Solutions==
A. '''Introduction of a PenaltyCalculator Mixin'''
* '''Solution:''' A new module `PenaltyCalculator` will be created to handle the penalty calculations. This module will contain methods for calculating submission, review, and team formation penalties.
* '''Benefit:''' It makes the penalty calculation logic reusable, keeps the code DRY, and ensures the logic is centralized.

B. '''Tracking Submission Dates'''
* '''Solution:''' Ensure that submission dates are explicitly tracked in the `Submission` model. Add a method to check if a submission is late based on the due date.
* '''Benefit:''' Provides a straightforward way to identify late submissions and apply penalties accordingly.

C. '''Tracking Team Formation Dates'''
* '''Solution:''' Use the team formation date in the `Team` model to track when a team is formed. Use this date to calculate penalties for late team formation.
* '''Benefit:''' Ensures that penalties for late team formation are applied consistently and accurately.

D. '''Handling Review Penalties'''
* '''Solution:''' Extend the `PenaltyCalculator` mixin to include methods for calculating penalties for late reviews. Ensure that review deadlines are tracked and used in penalty calculations.
* '''Benefit:''' Ensures that penalties for late reviews are applied consistently across different models.

E. '''Extensible Penalty Application'''
* '''Solution:''' Design the `PenaltyCalculator` mixin to be easily extensible, allowing new types of penalties to be added in the future. Use clear and transparent methods for debugging.
* '''Benefit:''' Keeps the penalty calculation logic modular and readable, making it easier to maintain and extend.

F. '''Code Maintainability and Readability'''
* '''Solution:''' Centralize the penalty calculation logic in the `PenaltyCalculator` mixin to avoid code duplication. Ensure that the mixin is included in relevant models where penalties need to be applied.
* '''Benefit:''' Reduces code duplication, making the codebase easier to maintain and ensuring that penalty logic is consistent across the application.

==UML Diagram==
[[File:PenaltyMixinUML.JPG]]

=Testing Plan=
We primarily tested using automated testing through RSpec. Since due dates are a relatively self-contained structure, RSpec testing was more than sufficient for covering all testing scenarios. Here are some of our test cases:

[[File:Copy_due_date_test.jpeg]]

[[File:Sort_unit_test.JPG]]

=Relevant Links=
* '''Github Repository:''' https://github.com/akuldevali/reimplementation-back-end
* '''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/129

=Team=

Mentor: Dr. Ed Gehringer - efg@ncsu.edu
* Akul Devali - devali@ncsu.edu
* Pete Chopelas - pechopel@ncsu.edu
* Snehil Behar - sbehar@ncsu.edu

File:PenaltyMixinUML.JPG

2024-11-13T04:57:05Z

Pechopel:

CSC/ECE 517 Fall 2024 - E2468. Reimplement due date

2024-10-31T03:22:10Z

Pechopel: /* Testing Plan */

File:Sort unit test.JPG

2024-10-31T03:18:47Z

Pechopel: Unit test for DueDate.sort_due_dates

== Summary ==
Unit test for DueDate.sort_due_dates

File:Copy due date test.jpeg

2024-10-31T03:18:11Z

Pechopel: Unit test for due_date.copy

== Summary ==
Unit test for due_date.copy

CSC/ECE 517 Fall 2024 - E2468. Reimplement due date

2024-10-31T03:14:14Z

Pechopel: /* Other changes */

CSC/ECE 517 Fall 2024 - E2468. Reimplement due date

2024-10-31T03:13:58Z

Pechopel: /* Design Goals */

CSC/ECE 517 Fall 2024 - E2468. Reimplement due date

2024-10-31T03:11:04Z

Pechopel: /* Other changes */

CSC/ECE 517 Fall 2024 - E2468. Reimplement due date

2024-10-31T03:02:59Z

Pechopel: /* Design Goals */

CSC/ECE 517 Fall 2024 - E2468. Reimplement due date

2024-10-31T02:57:49Z

Pechopel:

CSC/ECE 517 Fall 2024 - E2468. Reimplement due date

2024-10-31T02:57:29Z

Pechopel: /* Reimplemented Methods */

CSC/ECE 517 Fall 2024 - E2468. Reimplement due date

2024-10-31T02:22:48Z

Pechopel: /* Relevant Links */

CSC/ECE 517 Fall 2024

2024-10-29T23:09:08Z

Pechopel:

* [[CSC/ECE 517 Fall 2024 - E2452. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2453. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2024 - E2454. Refactor student_task.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb]]
* [[CSC/ECE 517 Fall 2024 - E2455. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2459. View for results of bidding]]
* [[CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management]]
* [[CSC/ECE 517 Fall 2024 - E2461. UI for Courses]]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2462._UI_for_Questionnaires CSC/ECE 517 Fall 2024 - E2462. UI for Questionnaire.rb]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2463_Implement_Front_End_for_Student_Task_List CSC/ECE 517 Fall 2024 - E2463. UI for Student Task List]
* [[CSC/ECE 517 Fall 2024 - E2464 UI for Project Topics (was: Sign_up_Topics)]]
* [[CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification]]
* [[CSC/ECE 517 Fall 2024 - E2466. UI for Impersonate User]]
* [[CSC/ECE 517 Fall 2024 - E2467. UI for View Submissions]]
* [[CSC/ECE 517 Fall 2024 - E2468. Reimplement due_date]]
* [[CSC/ECE 517 Fall 2024 - E2469. Reimplement grades/view_team]]
* [[CSC/ECE 517 Fall 2024 - E2470. Reimplement grades_controller]]
* [[CSC/ECE 517 Fall 2024 - E2471. Reimplement logger]]
* [[CSC/ECE 517 Fall 2024 - E2475. Reimplement student_task view]]
* [[CSC/ECE 517 Fall 2024 - E2478. Reimplement the Question hierarchy as Item hierarchy]]
* [[CSC/ECE 517 Fall 2024 - E2480. Implement testing for new Bookmarks Controller]]
* [[CSC/ECE 517 Fall 2024 - E2482. Reimplement heatgrid for reviews]]
* [[CSC/ECE 517 Fall 2024 - E2481 Reimplement response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - G2401 Refactor Graphql API endpoint for contribution metrics]]
* [[CSC/ECE 517 Fall 2024 - G2402 Refactor Graphql API endpoint for repositories]]

CSC/ECE 517 Fall 2024 - E2468. Reimplement due date

2024-10-29T23:06:09Z

Pechopel: Created page with "=About Expertiza= Expertiza is an open-source project built using Ruby on Rails. It provides a platform for instructors and students to manage, submit, and evaluate assignments and projects. Instructors can create, edit, and grade assignments, while students can collaborate in teams, submit their work, and review peers' submissions. Expertiza supports submission across various document types, including URLs and wiki pages. =Issues with previous Functionality= * Outda..."