https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&feedformat=atom&user=Skim253
Expertiza_Wiki - User contributions [en]
2026-05-16T09:56:15Z
User contributions
MediaWiki 1.41.0
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167301
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T23:03:37Z
<p>Skim253: /* Demo */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|800px]]<br />
<br />
When editing an assignment, due dates can be modified under the Due Dates tab. Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|800px]]<br />
<br />
In the Assignments tab, the current stage and stage deadline of each assignment is displayed.<br />
<br />
[[File:Due-date-topic-instructor.png|800px]]<br />
<br />
[[File:Due-date-topic-instructor-2.png|800px]]<br />
<br />
In the Topics subtab, due dates for each topic are displayed.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|800px]]<br />
<br />
Students can view due date information under <code>Current State</code> and <code>Stage Deadline</code>. The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|800px]]<br />
<br />
During the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|800px]]<br />
<br />
Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
=== Motivation ===<br />
<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
'''Modeling & Structural Issues'''<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
'''Permission & Behavior Issues'''<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions that combines both role-based and time-based constraints.<br />
<br />
=== Tasks Identified ===<br />
<br />
'''Modeling & Structural'''<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (<code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
'''Permission & Behavior'''<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules. Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility. This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
=== Architecture Overview ===<br />
<br />
[[File:Duedate-diagram.png|800px]]<br />
<br />
This diagram visualizes the redesigned architecture with five distinct layers:<br />
<br />
* '''Layer 1 (Blue)''': Parent models (Assignment, SignUpTopic) that own due dates<br />
* '''Layer 2 (Orange)''': DueDateActions module providing action-level queries<br />
* '''Layer 3 (Red)''': DueDate model managing core deadline data<br />
* '''Layer 4 (Orange)''': DueDatePermissions module evaluating permissions<br />
* '''Layer 5 (Green)''': Reference data models (DeadlineType, DeadlineRight, Participant)<br />
<br />
The flow works as follows: Parent models include DueDateActions, which queries DueDate objects. Each DueDate includes DueDatePermissions to evaluate whether actions are allowed based on DeadlineRight states and Participant role flags.<br />
<br />
=== DeadlineType Model ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table. In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
This leads to several structural issues:<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of semantic helper methods (e.g., <code>review?</code>, <code>submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure<br />
|- <br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.deadline_type_id</code><br />
|-<br />
| name || VARCHAR(255) || Unique symbolic name (e.g., <code>submission</code>, <code>review</code>)<br />
|-<br />
| description || TEXT || Human-readable explanation of the deadline category<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries<br />
|-<br />
! ID !! Name !! Description<br />
|-<br />
| 1 || submission || Student submission deadlines<br />
|-<br />
| 2 || review || Peer review deadlines<br />
|-<br />
| 3 || teammate_review || Team member evaluation deadlines<br />
|-<br />
| 5 || metareview || Meta-review deadlines (backward compatibility)<br />
|-<br />
| 6 || drop_topic || Topic drop deadlines<br />
|-<br />
| 7 || signup || Topic signup deadlines<br />
|-<br />
| 8 || team_formation || Team formation deadlines (duplicate cleaned)<br />
|-<br />
| 11 || quiz || Quiz completion deadlines<br />
|}<br />
<br />
=== DeadlineRight Model ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline:<br />
<br />
* '''OK''': Action is allowed without penalty<br />
* '''Late''': Action is allowed but marked as late<br />
* '''No''': Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, and <code>quiz_allowed_id</code>.<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure<br />
|-<br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.*_allowed_id</code> fields<br />
|-<br />
| name || VARCHAR(255) || Unique permission name (<code>No</code>, <code>Late</code>, <code>OK</code>)<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating the Single Responsibility Principle. Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Old design: class method that mixes concerns<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is focused on representing a single deadline entry. Behavior has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring<br />
|-<br />
! Concern !! Where It Lives<br />
|-<br />
| Permission checking || <code>DueDatePermissions</code> module (included in DueDate)<br />
|-<br />
| Deadline-related actions || <code>DueDateActions</code> module (included in parent models)<br />
|-<br />
| Deadline type semantics || <code>DeadlineType</code> model<br />
|-<br />
| Core deadline data || <code>DueDate</code> model<br />
|}<br />
<br />
Key improvements:<br />
* '''Instance-based behavior''': Replaced class methods with instance methods<br />
* '''Clear query methods''': Simple predicates like <code>upcoming?</code>, <code>overdue?</code><br />
* '''Scopes for common queries''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code><br />
<br />
=== DueDatePermissions Module ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks are split into two disconnected layers:<br />
<br />
'''Role-based permissions''' (in participant_helpers.rb):<br />
<syntaxhighlight lang="ruby"><br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
# ...<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
'''Deadline-based checks''' (in Assignment model):<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers never interact, leading to inconsistencies.<br />
<br />
==== Proposed Solution ====<br />
<br />
The <code>DueDatePermissions</code> module integrates both layers:<br />
<br />
{| class="wikitable"<br />
|+ Permission Methods<br />
|-<br />
! Method !! What It Checks<br />
|-<br />
| <code>can_submit?(participant)</code> || Submission deadline is OK/Late AND participant can submit<br />
|-<br />
| <code>can_review?(participant)</code> || Review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>can_take_quiz?(participant)</code> || Quiz deadline is OK/Late AND participant can take quiz<br />
|-<br />
| <code>can_review_teammate?(participant)</code> || Teammate review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Generic checker for any activity<br />
|-<br />
| <code>permission_status_for(action)</code> || Returns 'OK', 'Late', or 'No' for display<br />
|}<br />
<br />
=== DueDateActions Module ===<br />
<br />
The <code>DueDateActions</code> module provides a unified interface for models that own due dates (<code>Assignment</code> and <code>SignUpTopic</code>). This centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
==== Proposed Solution ====<br />
<br />
{| class="wikitable"<br />
|+ Methods in DueDateActions<br />
|-<br />
! Method !! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Checks if an activity is permitted at the current time<br />
|-<br />
| <code>submission_permissible?</code> || Convenience wrapper for submission checking<br />
|-<br />
| <code>review_permissible?</code> || Convenience wrapper for review checking<br />
|-<br />
| <code>next_due_date(topic_id)</code> || Resolves the next applicable deadline<br />
|-<br />
| <code>current_stage</code> || Returns human-readable stage name (e.g., "review", "submission")<br />
|-<br />
| <code>has_topic_specific_deadlines?</code> || Determines if assignment uses topic-specific deadlines<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code> || Utility for cloning due dates to another assignment<br />
|}<br />
<br />
==== Deadline Resolution Flow ====<br />
<br />
{| class="wikitable"<br />
|+ How next_due_date Works<br />
|-<br />
! Step !! Description<br />
|-<br />
| 1. Topic-specific check || If topic ID provided and assignment uses staggered deadlines, check topic-level deadlines first<br />
|-<br />
| 2. Assignment-level fallback || If no topic deadline exists, use nearest assignment-level deadline<br />
|-<br />
| 3. Permission evaluation || Delegate to DueDatePermissions to determine if action is allowed<br />
|}<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' — Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' — Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' — Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' — STI subclass for topic-specific deadlines<br />
* '''Assignment''' — Includes DueDateActions mixin<br />
* '''SignUpTopic''' — Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' — Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' — Deadline-related operations for parent models<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
== Testing ==<br />
<br />
This test suite provides coverage for both the Assignment model and the DueDate model.<br />
The Assignment tests also exercise all behaviors provided by the DueDateActions mixin, since that module is included directly in the Assignment class.<br />
<br />
The tests are designed to verify how deadlines influence allowed activities (submission, review, quiz, etc.), how the system determines the next relevant deadline, and how deadlines are ordered.<br />
<br />
=== Coverage Summary ===<br />
<br />
==== Assignment (DueDateActions mixin included) ====<br />
The Assignment spec validates:<br />
<br />
activity permission logic:<br />
* <code>activity_permissible?</code> – evaluates permissions using the next upcoming deadline<br />
* <code>activity_permissible_for?</code> – finds the most recent past deadline relative to a specific time<br />
<br />
deadline-based navigation:<br />
* <code>next_due_date</code><br />
* <code>deadlines_properly_ordered?</code><br />
<br />
delegation helpers such as:<br />
* <code>submission_permissible?</code><br />
* <code>review_permissible?</code><br />
<br />
These tests ensure that Assignment correctly interprets the state of its associated due dates.<br />
<br />
==== DueDate Model ====<br />
The DueDate spec validates:<br />
<br />
required field validations (parent, due_at, deadline_type_id)<br />
round field rules (cannot be zero or negative, sets default when nil)<br />
scopes:<br />
* <code>.upcoming</code><br />
* <code>.overdue</code><br />
* <code>.for_round</code><br />
* <code>.for_deadline_type</code><br />
<br />
instance methods:<br />
* <code>#overdue?</code>, <code>#upcoming?</code>, <code>#set</code>, <code>#copy</code>, <code>#deadline_type_name</code>, <code>#last_deadline?</code>, <code>#<=></code><br />
<br />
class methods:<br />
* <code>.sort_due_dates</code>, <code>.any_future_due_dates?</code>, <code>.copy</code><br />
<br />
callback:<br />
* <code>before_save :set_default_round</code><br />
<br />
=== Rationale for Test Design ===<br />
<br />
The test suites for DueDate and Assignment (including DueDateActions) are designed to validate two different layers of behavior:<br />
* DueDate tests verify record-level behavior: validations, scopes, and individual instance methods.<br />
* Assignment tests verify behavior that depends on collections of due dates, such as selecting the next deadline or determining whether an activity is permissible.<br />
<br />
All tests use real database records (DeadlineType, DeadlineRight, DueDate) to ensure that associations, validations, and permission checks reflect real application behavior.<br />
<br />
<br />
=== Test Structure ===<br />
<br />
The suite uses nested RSpec contexts:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'activity_permissible_for?' do<br />
context 'when past deadline exists' do<br />
it 'returns permission from most recent past deadline'<br />
end<br />
<br />
context 'when only future deadlines exist' do<br />
it 'returns false'<br />
end<br />
end </syntaxhighlight><br />
<br />
Contexts clearly describe the situation being tested, while individual examples describe expected behaviors.<br />
<br />
== Demo ==<br />
<br />
=== Demo Video ===<br />
<br />
[https://youtu.be/sTrVRGSaBlE Click to watch on YouTube]<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2555._Front_end_for_Participants_Page&diff=167300
CSC/ECE 517 Fall 2025 - E2555. Front end for Participants Page
2025-12-02T23:02:56Z
<p>Skim253: /* Demo Video */</p>
<hr />
<div>==Introduction==<br />
<br />
===Background===<br />
The Participants page displays a list of users associated with an assignment, including students and their roles.<br />
<br />
===Motivation===<br />
<br />
* '''Modernize the interface:''' Simplify the Participants table by reducing unnecessary columns and improving readability.<br />
* '''Improve role and permission management:''' Ensure table columns reflect real participant actions and roles.<br />
* '''Enhance maintainability:''' Refactor the front-end with clean code principles using TypeScript.<br />
<br />
===Tasks Identified===<br />
<br />
==== Simplify the Participants table ====<br />
<br />
* Global Search Filter - Search by Participant Name<br />
* Column header "Email Address" → "Email"<br />
* Column header "Name" → "Username"<br />
* Column header "Full Name" → "Name"<br />
* Consolidate actions: Replace Review, Submission, Metareview, Submit, Take Quiz with '''Submit''', '''Review''', '''Take Quiz''' (only shown when the assignment includes quizzes)<br />
* Remove the Metareview column.<br />
* Add a delete icon in each row to allow removing a participant - Use the standard icon from the standard icon library:[https://github.com/AnvithaReddyGutha/reimplementation-front-end/blob/main/design_document.md#icon-library].<br />
<br />
==== Remove Submit button for role changes and implement auto-saving ====<br />
<br />
* Provide a dropdown menu for selecting a participant’s role (e.g., Participant, Mentor, Reader, Reviewer, Submitter).<br />
* '''Auto-save behavior:''' When the dropdown value changes, the update is saved automatically—no separate "Submit" button needed.<br />
<br />
==== Add action links (copy/import/export participants) ====<br />
<br />
* '''Copy participants from course:''' Import existing course participants into the assignment.<br />
* '''Copy participants to course:''' Push assignment participants back to the course.<br />
* '''Import assignment participants:''' Upload participants in bulk from a file.<br />
* '''Export assignment participants:''' Download the participant list as CSV/Excel.<br />
* '''Back:''' Return to the assignment overview page.<br />
<br />
==Demo==<br />
===Demo Video===<br />
[https://youtu.be/sTrVRGSaBlE Click to watch on YouTube]<br />
<br />
===Demo Link===<br />
https://frontend-production-e7dc.up.railway.app/participants<br />
* login with '''admin''' '''password123'''<br />
* than go to '''/participant''' page<br />
<br />
==ParticipantsAPI Component==<br />
<br />
===Overview===<br />
The '''ParticipantsAPI''' component is the main container for managing assignment participants.<br />
It provides an integrated UI for viewing, editing, importing, exporting, and removing participants.<br />
It separates data handling (`useParticipants`) from presentation (`ParticipantTable`, `Toolbar`), following a modular and maintainable React + TypeScript architecture.<br />
<br />
===Core Responsibilities===<br />
<br />
* Display and manage the Participants table<br />
* Handle user interactions such as role updates and deletions<br />
* Integrate with the custom hook `useParticipants`<br />
* Connect import/export functionalities with CSV helpers<br />
* Provide feedback via alerts and modals<br />
<br />
===Main Hooks and States===<br />
<br />
* <code>useParticipants({ assignmentId: 1 })</code>: Fetches participant data and provides CRUD utilities.<br />
<br />
* <code>useState</code><br />
<code>alert</code>: Stores temporary UI feedback (success/info/error).<br />
<code>deleteModal</code>: Manages the confirmation modal for participant deletion.<br />
<code>requireQuiz</code>: Indicates whether quiz-related actions should be shown.<br />
<br />
===Alert System===<br />
<br />
* <code>showInfo(message)</code>, <code>showSuccess(message)</code>, <code>showError(message)</code> : Display contextual alerts with color-coded feedback. Alerts are auto-dismissed after 5 seconds.<br />
<br />
* <code>closeAlert()</code> : manually dismisses the alert.<br />
<br />
===Role Management===<br />
<br />
* <code>onRoleChange(id, newRoleId)</code> : Updates a participant’s role using <code>updateRole</code> from <code>useParticipants</code>. The update is automatically saved and confirmed with a success message.<br />
<br />
===Participant Removal===<br />
<br />
* <code>onRemoveClick(participant)</code> : Opens a confirmation modal before deletion.<br />
<br />
* <code>onConfirmDelete()</code> : Executes deletion and displays a success message.<br />
<br />
* <code>onCancelDelete()</code> : Closes the modal without changes.<br />
<br />
===Import/Export and Navigation===<br />
<br />
* <code>onImportFileChange(e)</code> : Imports participants from CSV and shows the number imported.<br />
<br />
* <code>onExport()</code> : Exports participant data as a CSV file.<br />
<br />
* <code>onCopyFromCourse()</code> / <code>onCopyToCourse()</code> : Placeholder actions for syncing data.<br />
<br />
* <code>onBack()</code> : Navigates back to the previous page.<br />
<br />
===UI Components===<br />
<br />
* <code>ParticipantToolbar</code>: Handles search and file import/export.<br />
<br />
* <code>ParticipantTable</code>: Displays participant data and role dropdowns.<br />
<br />
* <code>DeleteConfirmationModal</code>: Confirms participant removal.<br />
<br />
===Error Handling===<br />
<br />
* Automatically triggers <code>showError()</code> for <code>fetchError</code> or <code>deleteError</code>.<br />
<br />
* <code>try...catch</code> blocks in import logic handle parsing failures gracefully.<br />
<br />
===Styling===<br />
<br />
* Uses React-Bootstrap for layout (<code>Container</code>, <code>Row</code>, <code>Col</code>, <code>Alert</code>).<br />
<br />
* Inline styles control layout, typography, and spacing.<br />
<br />
* Includes a scoped <code><style></code> block for alert close button behavior.<br />
<br />
<br />
<br />
==Future Work==<br />
<br />
* '''Backend API integration:''': The backend endpoints (`GET /participants/student_tasks/:id`, `PATCH /participants/:id`) are not yet implemented and must be connected in a future phase.</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167238
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T19:51:16Z
<p>Skim253: </p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|800px]]<br />
<br />
When editing an assignment, due dates can be modified under the Due Dates tab. Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|800px]]<br />
<br />
In the Assignments tab, the current stage and stage deadline of each assignment is displayed.<br />
<br />
[[File:Due-date-topic-instructor.png|800px]]<br />
<br />
[[File:Due-date-topic-instructor-2.png|800px]]<br />
<br />
In the Topics subtab, due dates for each topic are displayed.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|800px]]<br />
<br />
Students can view due date information under <code>Current State</code> and <code>Stage Deadline</code>. The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|800px]]<br />
<br />
During the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|800px]]<br />
<br />
Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
=== Motivation ===<br />
<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
'''Modeling & Structural Issues'''<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
'''Permission & Behavior Issues'''<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions that combines both role-based and time-based constraints.<br />
<br />
=== Tasks Identified ===<br />
<br />
'''Modeling & Structural'''<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (<code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
'''Permission & Behavior'''<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules. Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility. This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
=== Architecture Overview ===<br />
<br />
[[File:Duedate-diagram.png|800px]]<br />
<br />
This diagram visualizes the redesigned architecture with five distinct layers:<br />
<br />
* '''Layer 1 (Blue)''': Parent models (Assignment, SignUpTopic) that own due dates<br />
* '''Layer 2 (Orange)''': DueDateActions module providing action-level queries<br />
* '''Layer 3 (Red)''': DueDate model managing core deadline data<br />
* '''Layer 4 (Orange)''': DueDatePermissions module evaluating permissions<br />
* '''Layer 5 (Green)''': Reference data models (DeadlineType, DeadlineRight, Participant)<br />
<br />
The flow works as follows: Parent models include DueDateActions, which queries DueDate objects. Each DueDate includes DueDatePermissions to evaluate whether actions are allowed based on DeadlineRight states and Participant role flags.<br />
<br />
=== DeadlineType Model ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table. In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
This leads to several structural issues:<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of semantic helper methods (e.g., <code>review?</code>, <code>submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure<br />
|- <br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.deadline_type_id</code><br />
|-<br />
| name || VARCHAR(255) || Unique symbolic name (e.g., <code>submission</code>, <code>review</code>)<br />
|-<br />
| description || TEXT || Human-readable explanation of the deadline category<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries<br />
|-<br />
! ID !! Name !! Description<br />
|-<br />
| 1 || submission || Student submission deadlines<br />
|-<br />
| 2 || review || Peer review deadlines<br />
|-<br />
| 3 || teammate_review || Team member evaluation deadlines<br />
|-<br />
| 5 || metareview || Meta-review deadlines (backward compatibility)<br />
|-<br />
| 6 || drop_topic || Topic drop deadlines<br />
|-<br />
| 7 || signup || Topic signup deadlines<br />
|-<br />
| 8 || team_formation || Team formation deadlines (duplicate cleaned)<br />
|-<br />
| 11 || quiz || Quiz completion deadlines<br />
|}<br />
<br />
=== DeadlineRight Model ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline:<br />
<br />
* '''OK''': Action is allowed without penalty<br />
* '''Late''': Action is allowed but marked as late<br />
* '''No''': Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, and <code>quiz_allowed_id</code>.<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure<br />
|-<br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.*_allowed_id</code> fields<br />
|-<br />
| name || VARCHAR(255) || Unique permission name (<code>No</code>, <code>Late</code>, <code>OK</code>)<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating the Single Responsibility Principle. Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Old design: class method that mixes concerns<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is focused on representing a single deadline entry. Behavior has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring<br />
|-<br />
! Concern !! Where It Lives<br />
|-<br />
| Permission checking || <code>DueDatePermissions</code> module (included in DueDate)<br />
|-<br />
| Deadline-related actions || <code>DueDateActions</code> module (included in parent models)<br />
|-<br />
| Deadline type semantics || <code>DeadlineType</code> model<br />
|-<br />
| Core deadline data || <code>DueDate</code> model<br />
|}<br />
<br />
Key improvements:<br />
* '''Instance-based behavior''': Replaced class methods with instance methods<br />
* '''Clear query methods''': Simple predicates like <code>upcoming?</code>, <code>overdue?</code><br />
* '''Scopes for common queries''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code><br />
<br />
=== DueDatePermissions Module ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks are split into two disconnected layers:<br />
<br />
'''Role-based permissions''' (in participant_helpers.rb):<br />
<syntaxhighlight lang="ruby"><br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
# ...<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
'''Deadline-based checks''' (in Assignment model):<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers never interact, leading to inconsistencies.<br />
<br />
==== Proposed Solution ====<br />
<br />
The <code>DueDatePermissions</code> module integrates both layers:<br />
<br />
{| class="wikitable"<br />
|+ Permission Methods<br />
|-<br />
! Method !! What It Checks<br />
|-<br />
| <code>can_submit?(participant)</code> || Submission deadline is OK/Late AND participant can submit<br />
|-<br />
| <code>can_review?(participant)</code> || Review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>can_take_quiz?(participant)</code> || Quiz deadline is OK/Late AND participant can take quiz<br />
|-<br />
| <code>can_review_teammate?(participant)</code> || Teammate review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Generic checker for any activity<br />
|-<br />
| <code>permission_status_for(action)</code> || Returns 'OK', 'Late', or 'No' for display<br />
|}<br />
<br />
=== DueDateActions Module ===<br />
<br />
The <code>DueDateActions</code> module provides a unified interface for models that own due dates (<code>Assignment</code> and <code>SignUpTopic</code>). This centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
==== Proposed Solution ====<br />
<br />
{| class="wikitable"<br />
|+ Methods in DueDateActions<br />
|-<br />
! Method !! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Checks if an activity is permitted at the current time<br />
|-<br />
| <code>submission_permissible?</code> || Convenience wrapper for submission checking<br />
|-<br />
| <code>review_permissible?</code> || Convenience wrapper for review checking<br />
|-<br />
| <code>next_due_date(topic_id)</code> || Resolves the next applicable deadline<br />
|-<br />
| <code>current_stage</code> || Returns human-readable stage name (e.g., "review", "submission")<br />
|-<br />
| <code>has_topic_specific_deadlines?</code> || Determines if assignment uses topic-specific deadlines<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code> || Utility for cloning due dates to another assignment<br />
|}<br />
<br />
==== Deadline Resolution Flow ====<br />
<br />
{| class="wikitable"<br />
|+ How next_due_date Works<br />
|-<br />
! Step !! Description<br />
|-<br />
| 1. Topic-specific check || If topic ID provided and assignment uses staggered deadlines, check topic-level deadlines first<br />
|-<br />
| 2. Assignment-level fallback || If no topic deadline exists, use nearest assignment-level deadline<br />
|-<br />
| 3. Permission evaluation || Delegate to DueDatePermissions to determine if action is allowed<br />
|}<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' — Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' — Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' — Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' — STI subclass for topic-specific deadlines<br />
* '''Assignment''' — Includes DueDateActions mixin<br />
* '''SignUpTopic''' — Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' — Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' — Deadline-related operations for parent models<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
== Testing ==<br />
<br />
This test suite provides coverage for both the Assignment model and the DueDate model.<br />
The Assignment tests also exercise all behaviors provided by the DueDateActions mixin, since that module is included directly in the Assignment class.<br />
<br />
The tests are designed to verify how deadlines influence allowed activities (submission, review, quiz, etc.), how the system determines the next relevant deadline, and how deadlines are ordered.<br />
<br />
=== Coverage Summary ===<br />
<br />
==== Assignment (DueDateActions mixin included) ====<br />
The Assignment spec validates:<br />
<br />
activity permission logic:<br />
* <code>activity_permissible?</code> – evaluates permissions using the next upcoming deadline<br />
* <code>activity_permissible_for?</code> – finds the most recent past deadline relative to a specific time<br />
<br />
deadline-based navigation:<br />
* <code>next_due_date</code><br />
* <code>deadlines_properly_ordered?</code><br />
<br />
delegation helpers such as:<br />
* <code>submission_permissible?</code><br />
* <code>review_permissible?</code><br />
<br />
These tests ensure that Assignment correctly interprets the state of its associated due dates.<br />
<br />
==== DueDate Model ====<br />
The DueDate spec validates:<br />
<br />
required field validations (parent, due_at, deadline_type_id)<br />
round field rules (cannot be zero or negative, sets default when nil)<br />
scopes:<br />
* <code>.upcoming</code><br />
* <code>.overdue</code><br />
* <code>.for_round</code><br />
* <code>.for_deadline_type</code><br />
<br />
instance methods:<br />
* <code>#overdue?</code>, <code>#upcoming?</code>, <code>#set</code>, <code>#copy</code>, <code>#deadline_type_name</code>, <code>#last_deadline?</code>, <code>#<=></code><br />
<br />
class methods:<br />
* <code>.sort_due_dates</code>, <code>.any_future_due_dates?</code>, <code>.copy</code><br />
<br />
callback:<br />
* <code>before_save :set_default_round</code><br />
<br />
=== Rationale for Test Design ===<br />
<br />
The test suites for DueDate and Assignment (including DueDateActions) are designed to validate two different layers of behavior:<br />
* DueDate tests verify record-level behavior: validations, scopes, and individual instance methods.<br />
* Assignment tests verify behavior that depends on collections of due dates, such as selecting the next deadline or determining whether an activity is permissible.<br />
<br />
All tests use real database records (DeadlineType, DeadlineRight, DueDate) to ensure that associations, validations, and permission checks reflect real application behavior.<br />
<br />
<br />
=== Test Structure ===<br />
<br />
The suite uses nested RSpec contexts:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'activity_permissible_for?' do<br />
context 'when past deadline exists' do<br />
it 'returns permission from most recent past deadline'<br />
end<br />
<br />
context 'when only future deadlines exist' do<br />
it 'returns false'<br />
end<br />
end </syntaxhighlight><br />
<br />
Contexts clearly describe the situation being tested, while individual examples describe expected behaviors.<br />
<br />
== Demo ==<br />
<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167231
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T19:23:01Z
<p>Skim253: /* Coverage Summary */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|800px]]<br />
<br />
When editing an assignment, due dates can be modified under the Due Dates tab. Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|800px]]<br />
<br />
In the Assignments tab, the current stage and stage deadline of each assignment is displayed.<br />
<br />
[[File:Due-date-topic-instructor.png|800px]]<br />
<br />
[[File:Due-date-topic-instructor-2.png|800px]]<br />
<br />
In the Topics subtab, due dates for each topic are displayed.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|800px]]<br />
<br />
Students can view due date information under <code>Current State</code> and <code>Stage Deadline</code>. The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|800px]]<br />
<br />
During the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|800px]]<br />
<br />
Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
=== Motivation ===<br />
<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
'''Modeling & Structural Issues'''<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
'''Permission & Behavior Issues'''<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions that combines both role-based and time-based constraints.<br />
<br />
=== Tasks Identified ===<br />
<br />
'''Modeling & Structural'''<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (<code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
'''Permission & Behavior'''<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules. Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility. This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
=== Architecture Overview ===<br />
<br />
[[File:Duedate-diagram.png|800px]]<br />
<br />
This diagram visualizes the redesigned architecture with five distinct layers:<br />
<br />
* '''Layer 1 (Blue)''': Parent models (Assignment, SignUpTopic) that own due dates<br />
* '''Layer 2 (Orange)''': DueDateActions module providing action-level queries<br />
* '''Layer 3 (Red)''': DueDate model managing core deadline data<br />
* '''Layer 4 (Orange)''': DueDatePermissions module evaluating permissions<br />
* '''Layer 5 (Green)''': Reference data models (DeadlineType, DeadlineRight, Participant)<br />
<br />
The flow works as follows: Parent models include DueDateActions, which queries DueDate objects. Each DueDate includes DueDatePermissions to evaluate whether actions are allowed based on DeadlineRight states and Participant role flags.<br />
<br />
=== DeadlineType Model ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table. In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
This leads to several structural issues:<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of semantic helper methods (e.g., <code>review?</code>, <code>submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure<br />
|- <br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.deadline_type_id</code><br />
|-<br />
| name || VARCHAR(255) || Unique symbolic name (e.g., <code>submission</code>, <code>review</code>)<br />
|-<br />
| description || TEXT || Human-readable explanation of the deadline category<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries<br />
|-<br />
! ID !! Name !! Description<br />
|-<br />
| 1 || submission || Student submission deadlines<br />
|-<br />
| 2 || review || Peer review deadlines<br />
|-<br />
| 3 || teammate_review || Team member evaluation deadlines<br />
|-<br />
| 5 || metareview || Meta-review deadlines (backward compatibility)<br />
|-<br />
| 6 || drop_topic || Topic drop deadlines<br />
|-<br />
| 7 || signup || Topic signup deadlines<br />
|-<br />
| 8 || team_formation || Team formation deadlines (duplicate cleaned)<br />
|-<br />
| 11 || quiz || Quiz completion deadlines<br />
|}<br />
<br />
=== DeadlineRight Model ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline:<br />
<br />
* '''OK''': Action is allowed without penalty<br />
* '''Late''': Action is allowed but marked as late<br />
* '''No''': Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, and <code>quiz_allowed_id</code>.<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure<br />
|-<br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.*_allowed_id</code> fields<br />
|-<br />
| name || VARCHAR(255) || Unique permission name (<code>No</code>, <code>Late</code>, <code>OK</code>)<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating the Single Responsibility Principle. Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Old design: class method that mixes concerns<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is focused on representing a single deadline entry. Behavior has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring<br />
|-<br />
! Concern !! Where It Lives<br />
|-<br />
| Permission checking || <code>DueDatePermissions</code> module (included in DueDate)<br />
|-<br />
| Deadline-related actions || <code>DueDateActions</code> module (included in parent models)<br />
|-<br />
| Deadline type semantics || <code>DeadlineType</code> model<br />
|-<br />
| Core deadline data || <code>DueDate</code> model<br />
|}<br />
<br />
Key improvements:<br />
* '''Instance-based behavior''': Replaced class methods with instance methods<br />
* '''Clear query methods''': Simple predicates like <code>upcoming?</code>, <code>overdue?</code><br />
* '''Scopes for common queries''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code><br />
<br />
=== DueDatePermissions Module ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks are split into two disconnected layers:<br />
<br />
'''Role-based permissions''' (in participant_helpers.rb):<br />
<syntaxhighlight lang="ruby"><br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
# ...<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
'''Deadline-based checks''' (in Assignment model):<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers never interact, leading to inconsistencies.<br />
<br />
==== Proposed Solution ====<br />
<br />
The <code>DueDatePermissions</code> module integrates both layers:<br />
<br />
{| class="wikitable"<br />
|+ Permission Methods<br />
|-<br />
! Method !! What It Checks<br />
|-<br />
| <code>can_submit?(participant)</code> || Submission deadline is OK/Late AND participant can submit<br />
|-<br />
| <code>can_review?(participant)</code> || Review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>can_take_quiz?(participant)</code> || Quiz deadline is OK/Late AND participant can take quiz<br />
|-<br />
| <code>can_review_teammate?(participant)</code> || Teammate review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Generic checker for any activity<br />
|-<br />
| <code>permission_status_for(action)</code> || Returns 'OK', 'Late', or 'No' for display<br />
|}<br />
<br />
=== DueDateActions Module ===<br />
<br />
The <code>DueDateActions</code> module provides a unified interface for models that own due dates (<code>Assignment</code> and <code>SignUpTopic</code>). This centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
==== Proposed Solution ====<br />
<br />
{| class="wikitable"<br />
|+ Methods in DueDateActions<br />
|-<br />
! Method !! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Checks if an activity is permitted at the current time<br />
|-<br />
| <code>submission_permissible?</code> || Convenience wrapper for submission checking<br />
|-<br />
| <code>review_permissible?</code> || Convenience wrapper for review checking<br />
|-<br />
| <code>next_due_date(topic_id)</code> || Resolves the next applicable deadline<br />
|-<br />
| <code>current_stage</code> || Returns human-readable stage name (e.g., "review", "submission")<br />
|-<br />
| <code>has_topic_specific_deadlines?</code> || Determines if assignment uses topic-specific deadlines<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code> || Utility for cloning due dates to another assignment<br />
|}<br />
<br />
==== Deadline Resolution Flow ====<br />
<br />
{| class="wikitable"<br />
|+ How next_due_date Works<br />
|-<br />
! Step !! Description<br />
|-<br />
| 1. Topic-specific check || If topic ID provided and assignment uses staggered deadlines, check topic-level deadlines first<br />
|-<br />
| 2. Assignment-level fallback || If no topic deadline exists, use nearest assignment-level deadline<br />
|-<br />
| 3. Permission evaluation || Delegate to DueDatePermissions to determine if action is allowed<br />
|}<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' — Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' — Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' — Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' — STI subclass for topic-specific deadlines<br />
* '''Assignment''' — Includes DueDateActions mixin<br />
* '''SignUpTopic''' — Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' — Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' — Deadline-related operations for parent models<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
== Testing Overview ==<br />
<br />
This test suite provides coverage for both the Assignment model and the DueDate model.<br />
The Assignment tests also exercise all behaviors provided by the DueDateActions mixin, since that module is included directly in the Assignment class.<br />
<br />
The tests are designed to verify how deadlines influence allowed activities (submission, review, quiz, etc.), how the system determines the next relevant deadline, and how deadlines are ordered.<br />
<br />
== Coverage Summary ==<br />
<br />
=== Assignment (DueDateActions mixin included) ===<br />
The Assignment spec validates:<br />
<br />
activity permission logic:<br />
* <code>activity_permissible?</code> – evaluates permissions using the next upcoming deadline<br />
* <code>activity_permissible_for?</code> – finds the most recent past deadline relative to a specific time<br />
<br />
deadline-based navigation:<br />
* <code>next_due_date</code><br />
* <code>deadlines_properly_ordered?</code><br />
<br />
delegation helpers such as:<br />
* <code>submission_permissible?</code><br />
* <code>review_permissible?</code><br />
<br />
These tests ensure that Assignment correctly interprets the state of its associated due dates.<br />
<br />
=== DueDate Model ===<br />
The DueDate spec validates:<br />
<br />
required field validations (parent, due_at, deadline_type_id)<br />
round field rules (cannot be zero or negative, sets default when nil)<br />
scopes:<br />
* <code>.upcoming</code><br />
* <code>.overdue</code><br />
* <code>.for_round</code><br />
* <code>.for_deadline_type</code><br />
<br />
instance methods:<br />
* <code>#overdue?</code>, <code>#upcoming?</code>, <code>#set</code>, <code>#copy</code>, <code>#deadline_type_name</code>, <code>#last_deadline?</code>, <code>#<=></code><br />
<br />
class methods:<br />
* <code>.sort_due_dates</code>, <code>.any_future_due_dates?</code>, <code>.copy</code><br />
<br />
callback:<br />
* <code>before_save :set_default_round</code><br />
<br />
== Rationale for Test Design ==<br />
<br />
The test suites for DueDate and Assignment (including DueDateActions) are designed to validate two different layers of behavior:<br />
* DueDate tests verify record-level behavior: validations, scopes, and individual instance methods.<br />
* Assignment tests verify behavior that depends on collections of due dates, such as selecting the next deadline or determining whether an activity is permissible.<br />
<br />
All tests use real database records (DeadlineType, DeadlineRight, DueDate) to ensure that associations, validations, and permission checks reflect real application behavior.<br />
<br />
<br />
== Test Structure ==<br />
<br />
The suite uses nested RSpec contexts:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'activity_permissible_for?' do<br />
context 'when past deadline exists' do<br />
it 'returns permission from most recent past deadline'<br />
end<br />
<br />
context 'when only future deadlines exist' do<br />
it 'returns false'<br />
end<br />
end </syntaxhighlight><br />
<br />
Contexts clearly describe the situation being tested, while individual examples describe expected behaviors.<br />
<br />
== Demo ==<br />
<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167230
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T19:20:47Z
<p>Skim253: /* Testing */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|800px]]<br />
<br />
When editing an assignment, due dates can be modified under the Due Dates tab. Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|800px]]<br />
<br />
In the Assignments tab, the current stage and stage deadline of each assignment is displayed.<br />
<br />
[[File:Due-date-topic-instructor.png|800px]]<br />
<br />
[[File:Due-date-topic-instructor-2.png|800px]]<br />
<br />
In the Topics subtab, due dates for each topic are displayed.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|800px]]<br />
<br />
Students can view due date information under <code>Current State</code> and <code>Stage Deadline</code>. The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|800px]]<br />
<br />
During the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|800px]]<br />
<br />
Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
=== Motivation ===<br />
<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
'''Modeling & Structural Issues'''<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
'''Permission & Behavior Issues'''<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions that combines both role-based and time-based constraints.<br />
<br />
=== Tasks Identified ===<br />
<br />
'''Modeling & Structural'''<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (<code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
'''Permission & Behavior'''<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules. Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility. This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
=== Architecture Overview ===<br />
<br />
[[File:Duedate-diagram.png|800px]]<br />
<br />
This diagram visualizes the redesigned architecture with five distinct layers:<br />
<br />
* '''Layer 1 (Blue)''': Parent models (Assignment, SignUpTopic) that own due dates<br />
* '''Layer 2 (Orange)''': DueDateActions module providing action-level queries<br />
* '''Layer 3 (Red)''': DueDate model managing core deadline data<br />
* '''Layer 4 (Orange)''': DueDatePermissions module evaluating permissions<br />
* '''Layer 5 (Green)''': Reference data models (DeadlineType, DeadlineRight, Participant)<br />
<br />
The flow works as follows: Parent models include DueDateActions, which queries DueDate objects. Each DueDate includes DueDatePermissions to evaluate whether actions are allowed based on DeadlineRight states and Participant role flags.<br />
<br />
=== DeadlineType Model ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table. In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
This leads to several structural issues:<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of semantic helper methods (e.g., <code>review?</code>, <code>submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure<br />
|- <br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.deadline_type_id</code><br />
|-<br />
| name || VARCHAR(255) || Unique symbolic name (e.g., <code>submission</code>, <code>review</code>)<br />
|-<br />
| description || TEXT || Human-readable explanation of the deadline category<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries<br />
|-<br />
! ID !! Name !! Description<br />
|-<br />
| 1 || submission || Student submission deadlines<br />
|-<br />
| 2 || review || Peer review deadlines<br />
|-<br />
| 3 || teammate_review || Team member evaluation deadlines<br />
|-<br />
| 5 || metareview || Meta-review deadlines (backward compatibility)<br />
|-<br />
| 6 || drop_topic || Topic drop deadlines<br />
|-<br />
| 7 || signup || Topic signup deadlines<br />
|-<br />
| 8 || team_formation || Team formation deadlines (duplicate cleaned)<br />
|-<br />
| 11 || quiz || Quiz completion deadlines<br />
|}<br />
<br />
=== DeadlineRight Model ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline:<br />
<br />
* '''OK''': Action is allowed without penalty<br />
* '''Late''': Action is allowed but marked as late<br />
* '''No''': Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, and <code>quiz_allowed_id</code>.<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure<br />
|-<br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.*_allowed_id</code> fields<br />
|-<br />
| name || VARCHAR(255) || Unique permission name (<code>No</code>, <code>Late</code>, <code>OK</code>)<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating the Single Responsibility Principle. Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Old design: class method that mixes concerns<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is focused on representing a single deadline entry. Behavior has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring<br />
|-<br />
! Concern !! Where It Lives<br />
|-<br />
| Permission checking || <code>DueDatePermissions</code> module (included in DueDate)<br />
|-<br />
| Deadline-related actions || <code>DueDateActions</code> module (included in parent models)<br />
|-<br />
| Deadline type semantics || <code>DeadlineType</code> model<br />
|-<br />
| Core deadline data || <code>DueDate</code> model<br />
|}<br />
<br />
Key improvements:<br />
* '''Instance-based behavior''': Replaced class methods with instance methods<br />
* '''Clear query methods''': Simple predicates like <code>upcoming?</code>, <code>overdue?</code><br />
* '''Scopes for common queries''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code><br />
<br />
=== DueDatePermissions Module ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks are split into two disconnected layers:<br />
<br />
'''Role-based permissions''' (in participant_helpers.rb):<br />
<syntaxhighlight lang="ruby"><br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
# ...<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
'''Deadline-based checks''' (in Assignment model):<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers never interact, leading to inconsistencies.<br />
<br />
==== Proposed Solution ====<br />
<br />
The <code>DueDatePermissions</code> module integrates both layers:<br />
<br />
{| class="wikitable"<br />
|+ Permission Methods<br />
|-<br />
! Method !! What It Checks<br />
|-<br />
| <code>can_submit?(participant)</code> || Submission deadline is OK/Late AND participant can submit<br />
|-<br />
| <code>can_review?(participant)</code> || Review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>can_take_quiz?(participant)</code> || Quiz deadline is OK/Late AND participant can take quiz<br />
|-<br />
| <code>can_review_teammate?(participant)</code> || Teammate review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Generic checker for any activity<br />
|-<br />
| <code>permission_status_for(action)</code> || Returns 'OK', 'Late', or 'No' for display<br />
|}<br />
<br />
=== DueDateActions Module ===<br />
<br />
The <code>DueDateActions</code> module provides a unified interface for models that own due dates (<code>Assignment</code> and <code>SignUpTopic</code>). This centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
==== Proposed Solution ====<br />
<br />
{| class="wikitable"<br />
|+ Methods in DueDateActions<br />
|-<br />
! Method !! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Checks if an activity is permitted at the current time<br />
|-<br />
| <code>submission_permissible?</code> || Convenience wrapper for submission checking<br />
|-<br />
| <code>review_permissible?</code> || Convenience wrapper for review checking<br />
|-<br />
| <code>next_due_date(topic_id)</code> || Resolves the next applicable deadline<br />
|-<br />
| <code>current_stage</code> || Returns human-readable stage name (e.g., "review", "submission")<br />
|-<br />
| <code>has_topic_specific_deadlines?</code> || Determines if assignment uses topic-specific deadlines<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code> || Utility for cloning due dates to another assignment<br />
|}<br />
<br />
==== Deadline Resolution Flow ====<br />
<br />
{| class="wikitable"<br />
|+ How next_due_date Works<br />
|-<br />
! Step !! Description<br />
|-<br />
| 1. Topic-specific check || If topic ID provided and assignment uses staggered deadlines, check topic-level deadlines first<br />
|-<br />
| 2. Assignment-level fallback || If no topic deadline exists, use nearest assignment-level deadline<br />
|-<br />
| 3. Permission evaluation || Delegate to DueDatePermissions to determine if action is allowed<br />
|}<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' — Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' — Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' — Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' — STI subclass for topic-specific deadlines<br />
* '''Assignment''' — Includes DueDateActions mixin<br />
* '''SignUpTopic''' — Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' — Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' — Deadline-related operations for parent models<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
== Testing Overview ==<br />
<br />
This test suite provides coverage for both the Assignment model and the DueDate model.<br />
The Assignment tests also exercise all behaviors provided by the DueDateActions mixin, since that module is included directly in the Assignment class.<br />
<br />
The tests are designed to verify how deadlines influence allowed activities (submission, review, quiz, etc.), how the system determines the next relevant deadline, and how deadlines are ordered.<br />
<br />
== Coverage Summary ==<br />
<br />
=== Assignment (DueDateActions mixin included) ===<br />
The Assignment spec validates:<br />
<br />
* activity permission logic:<br />
** <code>activity_permissible?</code> – evaluates permissions using the next upcoming deadline<br />
** <code>activity_permissible_for?</code> – finds the most recent past deadline relative to a specific time<br />
* deadline-based navigation:<br />
** <code>next_due_date</code><br />
** <code>deadlines_properly_ordered?</code><br />
* delegation helpers such as:<br />
** <code>submission_permissible?</code><br />
** <code>review_permissible?</code><br />
<br />
These tests ensure that Assignment correctly interprets the state of its associated due dates.<br />
<br />
=== DueDate Model ===<br />
The DueDate spec validates:<br />
<br />
* required field validations (parent, due_at, deadline_type_id)<br />
* round field rules (cannot be zero or negative, sets default when nil)<br />
* scopes:<br />
** <code>.upcoming</code><br />
** <code>.overdue</code><br />
** <code>.for_round</code><br />
** <code>.for_deadline_type</code><br />
* instance methods:<br />
** <code>#overdue?</code>, <code>#upcoming?</code>, <code>#set</code>, <code>#copy</code>, <code>#deadline_type_name</code>, <code>#last_deadline?</code>, <code>#<=></code><br />
* class methods:<br />
** <code>.sort_due_dates</code>, <code>.any_future_due_dates?</code>, <code>.copy</code><br />
* callback:<br />
** <code>before_save :set_default_round</code><br />
<br />
This ensures the model behaves correctly as an individual record, independent from Assignment.<br />
<br />
== Rationale for Test Design ==<br />
<br />
The test suites for DueDate and Assignment (including DueDateActions) are designed to validate two different layers of behavior:<br />
* DueDate tests verify record-level behavior: validations, scopes, and individual instance methods.<br />
* Assignment tests verify behavior that depends on collections of due dates, such as selecting the next deadline or determining whether an activity is permissible.<br />
<br />
All tests use real database records (DeadlineType, DeadlineRight, DueDate) to ensure that associations, validations, and permission checks reflect real application behavior.<br />
<br />
<br />
== Test Structure ==<br />
<br />
The suite uses nested RSpec contexts:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'activity_permissible_for?' do<br />
context 'when past deadline exists' do<br />
it 'returns permission from most recent past deadline'<br />
end<br />
<br />
context 'when only future deadlines exist' do<br />
it 'returns false'<br />
end<br />
end </syntaxhighlight><br />
<br />
Contexts clearly describe the situation being tested, while individual examples describe expected behaviors.<br />
<br />
== Demo ==<br />
<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167223
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T15:38:08Z
<p>Skim253: /* Proposed Solution */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|800px]]<br />
<br />
When editing an assignment, due dates can be modified under the Due Dates tab. Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|800px]]<br />
<br />
In the Assignments tab, the current stage and stage deadline of each assignment is displayed.<br />
<br />
[[File:Due-date-topic-instructor.png|800px]]<br />
<br />
[[File:Due-date-topic-instructor-2.png|800px]]<br />
<br />
In the Topics subtab, due dates for each topic are displayed.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|800px]]<br />
<br />
Students can view due date information under <code>Current State</code> and <code>Stage Deadline</code>. The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|800px]]<br />
<br />
During the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|800px]]<br />
<br />
Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
=== Motivation ===<br />
<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
'''Modeling & Structural Issues'''<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
'''Permission & Behavior Issues'''<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions that combines both role-based and time-based constraints.<br />
<br />
=== Tasks Identified ===<br />
<br />
'''Modeling & Structural'''<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (<code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
'''Permission & Behavior'''<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules. Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility. This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
=== Architecture Overview ===<br />
<br />
[[File:Duedate-diagram.png|800px]]<br />
<br />
This diagram visualizes the redesigned architecture with five distinct layers:<br />
<br />
* '''Layer 1 (Blue)''': Parent models (Assignment, SignUpTopic) that own due dates<br />
* '''Layer 2 (Orange)''': DueDateActions module providing action-level queries<br />
* '''Layer 3 (Red)''': DueDate model managing core deadline data<br />
* '''Layer 4 (Orange)''': DueDatePermissions module evaluating permissions<br />
* '''Layer 5 (Green)''': Reference data models (DeadlineType, DeadlineRight, Participant)<br />
<br />
The flow works as follows: Parent models include DueDateActions, which queries DueDate objects. Each DueDate includes DueDatePermissions to evaluate whether actions are allowed based on DeadlineRight states and Participant role flags.<br />
<br />
=== DeadlineType Model ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table. In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
This leads to several structural issues:<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of semantic helper methods (e.g., <code>review?</code>, <code>submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure<br />
|- <br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.deadline_type_id</code><br />
|-<br />
| name || VARCHAR(255) || Unique symbolic name (e.g., <code>submission</code>, <code>review</code>)<br />
|-<br />
| description || TEXT || Human-readable explanation of the deadline category<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries<br />
|-<br />
! ID !! Name !! Description<br />
|-<br />
| 1 || submission || Student submission deadlines<br />
|-<br />
| 2 || review || Peer review deadlines<br />
|-<br />
| 3 || teammate_review || Team member evaluation deadlines<br />
|-<br />
| 5 || metareview || Meta-review deadlines (backward compatibility)<br />
|-<br />
| 6 || drop_topic || Topic drop deadlines<br />
|-<br />
| 7 || signup || Topic signup deadlines<br />
|-<br />
| 8 || team_formation || Team formation deadlines (duplicate cleaned)<br />
|-<br />
| 11 || quiz || Quiz completion deadlines<br />
|}<br />
<br />
=== DeadlineRight Model ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline:<br />
<br />
* '''OK''': Action is allowed without penalty<br />
* '''Late''': Action is allowed but marked as late<br />
* '''No''': Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, and <code>quiz_allowed_id</code>.<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure<br />
|-<br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.*_allowed_id</code> fields<br />
|-<br />
| name || VARCHAR(255) || Unique permission name (<code>No</code>, <code>Late</code>, <code>OK</code>)<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating the Single Responsibility Principle. Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Old design: class method that mixes concerns<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is focused on representing a single deadline entry. Behavior has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring<br />
|-<br />
! Concern !! Where It Lives<br />
|-<br />
| Permission checking || <code>DueDatePermissions</code> module (included in DueDate)<br />
|-<br />
| Deadline-related actions || <code>DueDateActions</code> module (included in parent models)<br />
|-<br />
| Deadline type semantics || <code>DeadlineType</code> model<br />
|-<br />
| Core deadline data || <code>DueDate</code> model<br />
|}<br />
<br />
Key improvements:<br />
* '''Instance-based behavior''': Replaced class methods with instance methods<br />
* '''Clear query methods''': Simple predicates like <code>upcoming?</code>, <code>overdue?</code><br />
* '''Scopes for common queries''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code><br />
<br />
=== DueDatePermissions Module ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks are split into two disconnected layers:<br />
<br />
'''Role-based permissions''' (in participant_helpers.rb):<br />
<syntaxhighlight lang="ruby"><br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
# ...<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
'''Deadline-based checks''' (in Assignment model):<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers never interact, leading to inconsistencies.<br />
<br />
==== Proposed Solution ====<br />
<br />
The <code>DueDatePermissions</code> module integrates both layers:<br />
<br />
{| class="wikitable"<br />
|+ Permission Methods<br />
|-<br />
! Method !! What It Checks<br />
|-<br />
| <code>can_submit?(participant)</code> || Submission deadline is OK/Late AND participant can submit<br />
|-<br />
| <code>can_review?(participant)</code> || Review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>can_take_quiz?(participant)</code> || Quiz deadline is OK/Late AND participant can take quiz<br />
|-<br />
| <code>can_review_teammate?(participant)</code> || Teammate review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Generic checker for any activity<br />
|-<br />
| <code>permission_status_for(action)</code> || Returns 'OK', 'Late', or 'No' for display<br />
|}<br />
<br />
=== DueDateActions Module ===<br />
<br />
The <code>DueDateActions</code> module provides a unified interface for models that own due dates (<code>Assignment</code> and <code>SignUpTopic</code>). This centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
==== Proposed Solution ====<br />
<br />
{| class="wikitable"<br />
|+ Methods in DueDateActions<br />
|-<br />
! Method !! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Checks if an activity is permitted at the current time<br />
|-<br />
| <code>submission_permissible?</code> || Convenience wrapper for submission checking<br />
|-<br />
| <code>review_permissible?</code> || Convenience wrapper for review checking<br />
|-<br />
| <code>next_due_date(topic_id)</code> || Resolves the next applicable deadline<br />
|-<br />
| <code>current_stage</code> || Returns human-readable stage name (e.g., "review", "submission")<br />
|-<br />
| <code>has_topic_specific_deadlines?</code> || Determines if assignment uses topic-specific deadlines<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code> || Utility for cloning due dates to another assignment<br />
|}<br />
<br />
==== Deadline Resolution Flow ====<br />
<br />
{| class="wikitable"<br />
|+ How next_due_date Works<br />
|-<br />
! Step !! Description<br />
|-<br />
| 1. Topic-specific check || If topic ID provided and assignment uses staggered deadlines, check topic-level deadlines first<br />
|-<br />
| 2. Assignment-level fallback || If no topic deadline exists, use nearest assignment-level deadline<br />
|-<br />
| 3. Permission evaluation || Delegate to DueDatePermissions to determine if action is allowed<br />
|}<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' — Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' — Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' — Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' — STI subclass for topic-specific deadlines<br />
* '''Assignment''' — Includes DueDateActions mixin<br />
* '''SignUpTopic''' — Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' — Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' — Deadline-related operations for parent models<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the DueDate model using nested contexts, edge case coverage, and error handling.<br />
<br />
=== Current Coverage ===<br />
<br />
* '''Validations''': Required fields (parent, due_at, deadline_type_id), round validation, error messages<br />
* '''Scopes''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code> with edge cases<br />
* '''Instance Methods''': <code>#overdue?</code>, <code>#upcoming?</code>, <code>#set</code>, <code>#copy</code>, <code>#deadline_type_name</code>, <code>#last_deadline?</code>, <code>#<=></code><br />
* '''Class Methods''': <code>.sort_due_dates</code>, <code>.any_future_due_dates?</code>, <code>.copy</code><br />
* '''Callbacks''': <code>before_save :set_default_round</code><br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''Total examples''': 438 tests<br />
* '''DueDate model''': 60+ examples<br />
* '''Code coverage''': 100% of DueDate methods<br />
* '''Execution time''': ~12 seconds<br />
<br />
== Demo ==<br />
<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167222
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T15:36:47Z
<p>Skim253: /* Testing */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|800px]]<br />
<br />
When editing an assignment, due dates can be modified under the Due Dates tab. Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|800px]]<br />
<br />
In the Assignments tab, the current stage and stage deadline of each assignment is displayed.<br />
<br />
[[File:Due-date-topic-instructor.png|800px]]<br />
<br />
[[File:Due-date-topic-instructor-2.png|800px]]<br />
<br />
In the Topics subtab, due dates for each topic are displayed.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|800px]]<br />
<br />
Students can view due date information under <code>Current State</code> and <code>Stage Deadline</code>. The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|800px]]<br />
<br />
During the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|800px]]<br />
<br />
Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
=== Motivation ===<br />
<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
'''Modeling & Structural Issues'''<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
'''Permission & Behavior Issues'''<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions that combines both role-based and time-based constraints.<br />
<br />
=== Tasks Identified ===<br />
<br />
'''Modeling & Structural'''<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (<code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
'''Permission & Behavior'''<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules. Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility. This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
=== Architecture Overview ===<br />
<br />
[[File:Duedate-diagram.png|800px]]<br />
<br />
This diagram visualizes the redesigned architecture with five distinct layers:<br />
<br />
* '''Layer 1 (Blue)''': Parent models (Assignment, SignUpTopic) that own due dates<br />
* '''Layer 2 (Orange)''': DueDateActions module providing action-level queries<br />
* '''Layer 3 (Red)''': DueDate model managing core deadline data<br />
* '''Layer 4 (Orange)''': DueDatePermissions module evaluating permissions<br />
* '''Layer 5 (Green)''': Reference data models (DeadlineType, DeadlineRight, Participant)<br />
<br />
The flow works as follows: Parent models include DueDateActions, which queries DueDate objects. Each DueDate includes DueDatePermissions to evaluate whether actions are allowed based on DeadlineRight states and Participant role flags.<br />
<br />
=== 1. DeadlineType Model ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table. In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
This leads to several structural issues:<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of semantic helper methods (e.g., <code>review?</code>, <code>submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure<br />
|- <br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.deadline_type_id</code><br />
|-<br />
| name || VARCHAR(255) || Unique symbolic name (e.g., <code>submission</code>, <code>review</code>)<br />
|-<br />
| description || TEXT || Human-readable explanation of the deadline category<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries<br />
|-<br />
! ID !! Name !! Description<br />
|-<br />
| 1 || submission || Student submission deadlines<br />
|-<br />
| 2 || review || Peer review deadlines<br />
|-<br />
| 3 || teammate_review || Team member evaluation deadlines<br />
|-<br />
| 5 || metareview || Meta-review deadlines (backward compatibility)<br />
|-<br />
| 6 || drop_topic || Topic drop deadlines<br />
|-<br />
| 7 || signup || Topic signup deadlines<br />
|-<br />
| 8 || team_formation || Team formation deadlines (duplicate cleaned)<br />
|-<br />
| 11 || quiz || Quiz completion deadlines<br />
|}<br />
<br />
=== 2. DeadlineRight Model ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline:<br />
<br />
* '''OK''': Action is allowed without penalty<br />
* '''Late''': Action is allowed but marked as late<br />
* '''No''': Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, and <code>quiz_allowed_id</code>.<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure<br />
|-<br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.*_allowed_id</code> fields<br />
|-<br />
| name || VARCHAR(255) || Unique permission name (<code>No</code>, <code>Late</code>, <code>OK</code>)<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
=== 3. DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating the Single Responsibility Principle. Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Old design: class method that mixes concerns<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is focused on representing a single deadline entry. Behavior has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring<br />
|-<br />
! Concern !! Where It Lives<br />
|-<br />
| Permission checking || <code>DueDatePermissions</code> module (included in DueDate)<br />
|-<br />
| Deadline-related actions || <code>DueDateActions</code> module (included in parent models)<br />
|-<br />
| Deadline type semantics || <code>DeadlineType</code> model<br />
|-<br />
| Core deadline data || <code>DueDate</code> model<br />
|}<br />
<br />
Key improvements:<br />
* '''Instance-based behavior''': Replaced class methods with instance methods<br />
* '''Clear query methods''': Simple predicates like <code>upcoming?</code>, <code>overdue?</code><br />
* '''Scopes for common queries''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code><br />
<br />
=== 4. DueDatePermissions Module ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks are split into two disconnected layers:<br />
<br />
'''Role-based permissions''' (in participant_helpers.rb):<br />
<syntaxhighlight lang="ruby"><br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
# ...<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
'''Deadline-based checks''' (in Assignment model):<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers never interact, leading to inconsistencies.<br />
<br />
==== Proposed Solution ====<br />
<br />
The <code>DueDatePermissions</code> module integrates both layers:<br />
<br />
{| class="wikitable"<br />
|+ Permission Methods<br />
|-<br />
! Method !! What It Checks<br />
|-<br />
| <code>can_submit?(participant)</code> || Submission deadline is OK/Late AND participant can submit<br />
|-<br />
| <code>can_review?(participant)</code> || Review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>can_take_quiz?(participant)</code> || Quiz deadline is OK/Late AND participant can take quiz<br />
|-<br />
| <code>can_review_teammate?(participant)</code> || Teammate review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Generic checker for any activity<br />
|-<br />
| <code>permission_status_for(action)</code> || Returns 'OK', 'Late', or 'No' for display<br />
|}<br />
<br />
=== 5. DueDateActions Module ===<br />
<br />
The <code>DueDateActions</code> module provides a unified interface for models that own due dates (<code>Assignment</code> and <code>SignUpTopic</code>). This centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
==== Proposed Solution ====<br />
<br />
{| class="wikitable"<br />
|+ Methods in DueDateActions<br />
|-<br />
! Method !! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Checks if an activity is permitted at the current time<br />
|-<br />
| <code>submission_permissible?</code> || Convenience wrapper for submission checking<br />
|-<br />
| <code>review_permissible?</code> || Convenience wrapper for review checking<br />
|-<br />
| <code>next_due_date(topic_id)</code> || Resolves the next applicable deadline<br />
|-<br />
| <code>current_stage</code> || Returns human-readable stage name (e.g., "review", "submission")<br />
|-<br />
| <code>has_topic_specific_deadlines?</code> || Determines if assignment uses topic-specific deadlines<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code> || Utility for cloning due dates to another assignment<br />
|}<br />
<br />
==== Deadline Resolution Flow ====<br />
<br />
{| class="wikitable"<br />
|+ How next_due_date Works<br />
|-<br />
! Step !! Description<br />
|-<br />
| 1. Topic-specific check || If topic ID provided and assignment uses staggered deadlines, check topic-level deadlines first<br />
|-<br />
| 2. Assignment-level fallback || If no topic deadline exists, use nearest assignment-level deadline<br />
|-<br />
| 3. Permission evaluation || Delegate to DueDatePermissions to determine if action is allowed<br />
|}<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' — Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' — Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' — Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' — STI subclass for topic-specific deadlines<br />
* '''Assignment''' — Includes DueDateActions mixin<br />
* '''SignUpTopic''' — Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' — Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' — Deadline-related operations for parent models<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the DueDate model using nested contexts, edge case coverage, and error handling.<br />
<br />
=== Current Coverage ===<br />
<br />
* '''Validations''': Required fields (parent, due_at, deadline_type_id), round validation, error messages<br />
* '''Scopes''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code> with edge cases<br />
* '''Instance Methods''': <code>#overdue?</code>, <code>#upcoming?</code>, <code>#set</code>, <code>#copy</code>, <code>#deadline_type_name</code>, <code>#last_deadline?</code>, <code>#<=></code><br />
* '''Class Methods''': <code>.sort_due_dates</code>, <code>.any_future_due_dates?</code>, <code>.copy</code><br />
* '''Callbacks''': <code>before_save :set_default_round</code><br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''Total examples''': 438 tests<br />
* '''DueDate model''': 60+ examples<br />
* '''Code coverage''': 100% of DueDate methods<br />
* '''Execution time''': ~12 seconds<br />
<br />
== Demo ==<br />
<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167221
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T15:36:13Z
<p>Skim253: /* Purpose */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|800px]]<br />
<br />
When editing an assignment, due dates can be modified under the Due Dates tab. Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|800px]]<br />
<br />
In the Assignments tab, the current stage and stage deadline of each assignment is displayed.<br />
<br />
[[File:Due-date-topic-instructor.png|800px]]<br />
<br />
[[File:Due-date-topic-instructor-2.png|800px]]<br />
<br />
In the Topics subtab, due dates for each topic are displayed.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|800px]]<br />
<br />
Students can view due date information under <code>Current State</code> and <code>Stage Deadline</code>. The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|800px]]<br />
<br />
During the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|800px]]<br />
<br />
Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
=== Motivation ===<br />
<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
'''Modeling & Structural Issues'''<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
'''Permission & Behavior Issues'''<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions that combines both role-based and time-based constraints.<br />
<br />
=== Tasks Identified ===<br />
<br />
'''Modeling & Structural'''<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (<code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
'''Permission & Behavior'''<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules. Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility. This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
=== Architecture Overview ===<br />
<br />
[[File:Duedate-diagram.png|800px]]<br />
<br />
This diagram visualizes the redesigned architecture with five distinct layers:<br />
<br />
* '''Layer 1 (Blue)''': Parent models (Assignment, SignUpTopic) that own due dates<br />
* '''Layer 2 (Orange)''': DueDateActions module providing action-level queries<br />
* '''Layer 3 (Red)''': DueDate model managing core deadline data<br />
* '''Layer 4 (Orange)''': DueDatePermissions module evaluating permissions<br />
* '''Layer 5 (Green)''': Reference data models (DeadlineType, DeadlineRight, Participant)<br />
<br />
The flow works as follows: Parent models include DueDateActions, which queries DueDate objects. Each DueDate includes DueDatePermissions to evaluate whether actions are allowed based on DeadlineRight states and Participant role flags.<br />
<br />
=== 1. DeadlineType Model ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table. In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
This leads to several structural issues:<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of semantic helper methods (e.g., <code>review?</code>, <code>submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure<br />
|- <br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.deadline_type_id</code><br />
|-<br />
| name || VARCHAR(255) || Unique symbolic name (e.g., <code>submission</code>, <code>review</code>)<br />
|-<br />
| description || TEXT || Human-readable explanation of the deadline category<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries<br />
|-<br />
! ID !! Name !! Description<br />
|-<br />
| 1 || submission || Student submission deadlines<br />
|-<br />
| 2 || review || Peer review deadlines<br />
|-<br />
| 3 || teammate_review || Team member evaluation deadlines<br />
|-<br />
| 5 || metareview || Meta-review deadlines (backward compatibility)<br />
|-<br />
| 6 || drop_topic || Topic drop deadlines<br />
|-<br />
| 7 || signup || Topic signup deadlines<br />
|-<br />
| 8 || team_formation || Team formation deadlines (duplicate cleaned)<br />
|-<br />
| 11 || quiz || Quiz completion deadlines<br />
|}<br />
<br />
=== 2. DeadlineRight Model ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline:<br />
<br />
* '''OK''': Action is allowed without penalty<br />
* '''Late''': Action is allowed but marked as late<br />
* '''No''': Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, and <code>quiz_allowed_id</code>.<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure<br />
|-<br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.*_allowed_id</code> fields<br />
|-<br />
| name || VARCHAR(255) || Unique permission name (<code>No</code>, <code>Late</code>, <code>OK</code>)<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
=== 3. DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating the Single Responsibility Principle. Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Old design: class method that mixes concerns<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is focused on representing a single deadline entry. Behavior has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring<br />
|-<br />
! Concern !! Where It Lives<br />
|-<br />
| Permission checking || <code>DueDatePermissions</code> module (included in DueDate)<br />
|-<br />
| Deadline-related actions || <code>DueDateActions</code> module (included in parent models)<br />
|-<br />
| Deadline type semantics || <code>DeadlineType</code> model<br />
|-<br />
| Core deadline data || <code>DueDate</code> model<br />
|}<br />
<br />
Key improvements:<br />
* '''Instance-based behavior''': Replaced class methods with instance methods<br />
* '''Clear query methods''': Simple predicates like <code>upcoming?</code>, <code>overdue?</code><br />
* '''Scopes for common queries''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code><br />
<br />
=== 4. DueDatePermissions Module ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks are split into two disconnected layers:<br />
<br />
'''Role-based permissions''' (in participant_helpers.rb):<br />
<syntaxhighlight lang="ruby"><br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
# ...<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
'''Deadline-based checks''' (in Assignment model):<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers never interact, leading to inconsistencies.<br />
<br />
==== Proposed Solution ====<br />
<br />
The <code>DueDatePermissions</code> module integrates both layers:<br />
<br />
{| class="wikitable"<br />
|+ Permission Methods<br />
|-<br />
! Method !! What It Checks<br />
|-<br />
| <code>can_submit?(participant)</code> || Submission deadline is OK/Late AND participant can submit<br />
|-<br />
| <code>can_review?(participant)</code> || Review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>can_take_quiz?(participant)</code> || Quiz deadline is OK/Late AND participant can take quiz<br />
|-<br />
| <code>can_review_teammate?(participant)</code> || Teammate review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Generic checker for any activity<br />
|-<br />
| <code>permission_status_for(action)</code> || Returns 'OK', 'Late', or 'No' for display<br />
|}<br />
<br />
=== 5. DueDateActions Module ===<br />
<br />
The <code>DueDateActions</code> module provides a unified interface for models that own due dates (<code>Assignment</code> and <code>SignUpTopic</code>). This centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
==== Proposed Solution ====<br />
<br />
{| class="wikitable"<br />
|+ Methods in DueDateActions<br />
|-<br />
! Method !! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Checks if an activity is permitted at the current time<br />
|-<br />
| <code>submission_permissible?</code> || Convenience wrapper for submission checking<br />
|-<br />
| <code>review_permissible?</code> || Convenience wrapper for review checking<br />
|-<br />
| <code>next_due_date(topic_id)</code> || Resolves the next applicable deadline<br />
|-<br />
| <code>current_stage</code> || Returns human-readable stage name (e.g., "review", "submission")<br />
|-<br />
| <code>has_topic_specific_deadlines?</code> || Determines if assignment uses topic-specific deadlines<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code> || Utility for cloning due dates to another assignment<br />
|}<br />
<br />
==== Deadline Resolution Flow ====<br />
<br />
{| class="wikitable"<br />
|+ How next_due_date Works<br />
|-<br />
! Step !! Description<br />
|-<br />
| 1. Topic-specific check || If topic ID provided and assignment uses staggered deadlines, check topic-level deadlines first<br />
|-<br />
| 2. Assignment-level fallback || If no topic deadline exists, use nearest assignment-level deadline<br />
|-<br />
| 3. Permission evaluation || Delegate to DueDatePermissions to determine if action is allowed<br />
|}<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' — Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' — Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' — Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' — STI subclass for topic-specific deadlines<br />
* '''Assignment''' — Includes DueDateActions mixin<br />
* '''SignUpTopic''' — Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' — Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' — Deadline-related operations for parent models<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the DueDate model using nested contexts, edge case coverage, and error handling.<br />
<br />
=== Current Coverage ===<br />
<br />
* '''Validations''': Required fields (parent, due_at, deadline_type_id), round validation, error messages<br />
* '''Scopes''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code> with edge cases<br />
* '''Instance Methods''': <code>#overdue?</code>, <code>#upcoming?</code>, <code>#set</code>, <code>#copy</code>, <code>#deadline_type_name</code>, <code>#last_deadline?</code>, <code>#<=></code><br />
* '''Class Methods''': <code>.sort_due_dates</code>, <code>.any_future_due_dates?</code>, <code>.copy</code><br />
* '''Callbacks''': <code>before_save :set_default_round</code><br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Planned Future Tests ===<br />
<br />
* '''DueDatePermissions module''': Test <code>can_submit?</code>, <code>can_review?</code>, <code>can_take_quiz?</code> with participant parameters<br />
* '''DueDateActions module''': Test <code>activity_permissible?</code>, <code>next_due_date</code> in Assignment context<br />
* '''Integration tests''': Combined role-based and time-based permission logic<br />
<br />
=== Test Metrics ===<br />
<br />
* '''Total examples''': 438 tests<br />
* '''DueDate model''': 60+ examples<br />
* '''Code coverage''': 100% of DueDate methods<br />
* '''Execution time''': ~12 seconds<br />
<br />
== Demo ==<br />
<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167220
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T15:35:31Z
<p>Skim253: /* Deadline Resolution Flow */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|800px]]<br />
<br />
When editing an assignment, due dates can be modified under the Due Dates tab. Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|800px]]<br />
<br />
In the Assignments tab, the current stage and stage deadline of each assignment is displayed.<br />
<br />
[[File:Due-date-topic-instructor.png|800px]]<br />
<br />
[[File:Due-date-topic-instructor-2.png|800px]]<br />
<br />
In the Topics subtab, due dates for each topic are displayed.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|800px]]<br />
<br />
Students can view due date information under <code>Current State</code> and <code>Stage Deadline</code>. The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|800px]]<br />
<br />
During the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|800px]]<br />
<br />
Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
=== Motivation ===<br />
<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
'''Modeling & Structural Issues'''<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
'''Permission & Behavior Issues'''<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions that combines both role-based and time-based constraints.<br />
<br />
=== Tasks Identified ===<br />
<br />
'''Modeling & Structural'''<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (<code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
'''Permission & Behavior'''<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules. Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility. This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
=== Architecture Overview ===<br />
<br />
[[File:Duedate-diagram.png|800px]]<br />
<br />
This diagram visualizes the redesigned architecture with five distinct layers:<br />
<br />
* '''Layer 1 (Blue)''': Parent models (Assignment, SignUpTopic) that own due dates<br />
* '''Layer 2 (Orange)''': DueDateActions module providing action-level queries<br />
* '''Layer 3 (Red)''': DueDate model managing core deadline data<br />
* '''Layer 4 (Orange)''': DueDatePermissions module evaluating permissions<br />
* '''Layer 5 (Green)''': Reference data models (DeadlineType, DeadlineRight, Participant)<br />
<br />
The flow works as follows: Parent models include DueDateActions, which queries DueDate objects. Each DueDate includes DueDatePermissions to evaluate whether actions are allowed based on DeadlineRight states and Participant role flags.<br />
<br />
=== 1. DeadlineType Model ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table. In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
This leads to several structural issues:<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of semantic helper methods (e.g., <code>review?</code>, <code>submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure<br />
|- <br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.deadline_type_id</code><br />
|-<br />
| name || VARCHAR(255) || Unique symbolic name (e.g., <code>submission</code>, <code>review</code>)<br />
|-<br />
| description || TEXT || Human-readable explanation of the deadline category<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries<br />
|-<br />
! ID !! Name !! Description<br />
|-<br />
| 1 || submission || Student submission deadlines<br />
|-<br />
| 2 || review || Peer review deadlines<br />
|-<br />
| 3 || teammate_review || Team member evaluation deadlines<br />
|-<br />
| 5 || metareview || Meta-review deadlines (backward compatibility)<br />
|-<br />
| 6 || drop_topic || Topic drop deadlines<br />
|-<br />
| 7 || signup || Topic signup deadlines<br />
|-<br />
| 8 || team_formation || Team formation deadlines (duplicate cleaned)<br />
|-<br />
| 11 || quiz || Quiz completion deadlines<br />
|}<br />
<br />
=== 2. DeadlineRight Model ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline:<br />
<br />
* '''OK''': Action is allowed without penalty<br />
* '''Late''': Action is allowed but marked as late<br />
* '''No''': Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, and <code>quiz_allowed_id</code>.<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure<br />
|-<br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.*_allowed_id</code> fields<br />
|-<br />
| name || VARCHAR(255) || Unique permission name (<code>No</code>, <code>Late</code>, <code>OK</code>)<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
=== 3. DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating the Single Responsibility Principle. Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Old design: class method that mixes concerns<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is focused on representing a single deadline entry. Behavior has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring<br />
|-<br />
! Concern !! Where It Lives<br />
|-<br />
| Permission checking || <code>DueDatePermissions</code> module (included in DueDate)<br />
|-<br />
| Deadline-related actions || <code>DueDateActions</code> module (included in parent models)<br />
|-<br />
| Deadline type semantics || <code>DeadlineType</code> model<br />
|-<br />
| Core deadline data || <code>DueDate</code> model<br />
|}<br />
<br />
Key improvements:<br />
* '''Instance-based behavior''': Replaced class methods with instance methods<br />
* '''Clear query methods''': Simple predicates like <code>upcoming?</code>, <code>overdue?</code><br />
* '''Scopes for common queries''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code><br />
<br />
=== 4. DueDatePermissions Module ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks are split into two disconnected layers:<br />
<br />
'''Role-based permissions''' (in participant_helpers.rb):<br />
<syntaxhighlight lang="ruby"><br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
# ...<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
'''Deadline-based checks''' (in Assignment model):<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers never interact, leading to inconsistencies.<br />
<br />
==== Proposed Solution ====<br />
<br />
The <code>DueDatePermissions</code> module integrates both layers:<br />
<br />
{| class="wikitable"<br />
|+ Permission Methods<br />
|-<br />
! Method !! What It Checks<br />
|-<br />
| <code>can_submit?(participant)</code> || Submission deadline is OK/Late AND participant can submit<br />
|-<br />
| <code>can_review?(participant)</code> || Review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>can_take_quiz?(participant)</code> || Quiz deadline is OK/Late AND participant can take quiz<br />
|-<br />
| <code>can_review_teammate?(participant)</code> || Teammate review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Generic checker for any activity<br />
|-<br />
| <code>permission_status_for(action)</code> || Returns 'OK', 'Late', or 'No' for display<br />
|}<br />
<br />
=== 5. DueDateActions Module ===<br />
<br />
The <code>DueDateActions</code> module provides a unified interface for models that own due dates (<code>Assignment</code> and <code>SignUpTopic</code>). This centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
==== Purpose ====<br />
<br />
{| class="wikitable"<br />
|+ Methods in DueDateActions<br />
|-<br />
! Method !! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Checks if an activity is permitted at the current time<br />
|-<br />
| <code>submission_permissible?</code> || Convenience wrapper for submission checking<br />
|-<br />
| <code>review_permissible?</code> || Convenience wrapper for review checking<br />
|-<br />
| <code>next_due_date(topic_id)</code> || Resolves the next applicable deadline<br />
|-<br />
| <code>current_stage</code> || Returns human-readable stage name (e.g., "review", "submission")<br />
|-<br />
| <code>has_topic_specific_deadlines?</code> || Determines if assignment uses topic-specific deadlines<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code> || Utility for cloning due dates to another assignment<br />
|}<br />
<br />
==== Deadline Resolution Flow ====<br />
<br />
{| class="wikitable"<br />
|+ How next_due_date Works<br />
|-<br />
! Step !! Description<br />
|-<br />
| 1. Topic-specific check || If topic ID provided and assignment uses staggered deadlines, check topic-level deadlines first<br />
|-<br />
| 2. Assignment-level fallback || If no topic deadline exists, use nearest assignment-level deadline<br />
|-<br />
| 3. Permission evaluation || Delegate to DueDatePermissions to determine if action is allowed<br />
|}<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' — Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' — Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' — Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' — STI subclass for topic-specific deadlines<br />
* '''Assignment''' — Includes DueDateActions mixin<br />
* '''SignUpTopic''' — Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' — Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' — Deadline-related operations for parent models<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the DueDate model using nested contexts, edge case coverage, and error handling.<br />
<br />
=== Current Coverage ===<br />
<br />
* '''Validations''': Required fields (parent, due_at, deadline_type_id), round validation, error messages<br />
* '''Scopes''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code> with edge cases<br />
* '''Instance Methods''': <code>#overdue?</code>, <code>#upcoming?</code>, <code>#set</code>, <code>#copy</code>, <code>#deadline_type_name</code>, <code>#last_deadline?</code>, <code>#<=></code><br />
* '''Class Methods''': <code>.sort_due_dates</code>, <code>.any_future_due_dates?</code>, <code>.copy</code><br />
* '''Callbacks''': <code>before_save :set_default_round</code><br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Planned Future Tests ===<br />
<br />
* '''DueDatePermissions module''': Test <code>can_submit?</code>, <code>can_review?</code>, <code>can_take_quiz?</code> with participant parameters<br />
* '''DueDateActions module''': Test <code>activity_permissible?</code>, <code>next_due_date</code> in Assignment context<br />
* '''Integration tests''': Combined role-based and time-based permission logic<br />
<br />
=== Test Metrics ===<br />
<br />
* '''Total examples''': 438 tests<br />
* '''DueDate model''': 60+ examples<br />
* '''Code coverage''': 100% of DueDate methods<br />
* '''Execution time''': ~12 seconds<br />
<br />
== Demo ==<br />
<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167219
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T15:34:53Z
<p>Skim253: /* Proposed Solution */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|800px]]<br />
<br />
When editing an assignment, due dates can be modified under the Due Dates tab. Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|800px]]<br />
<br />
In the Assignments tab, the current stage and stage deadline of each assignment is displayed.<br />
<br />
[[File:Due-date-topic-instructor.png|800px]]<br />
<br />
[[File:Due-date-topic-instructor-2.png|800px]]<br />
<br />
In the Topics subtab, due dates for each topic are displayed.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|800px]]<br />
<br />
Students can view due date information under <code>Current State</code> and <code>Stage Deadline</code>. The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|800px]]<br />
<br />
During the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|800px]]<br />
<br />
Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
=== Motivation ===<br />
<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
'''Modeling & Structural Issues'''<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
'''Permission & Behavior Issues'''<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions that combines both role-based and time-based constraints.<br />
<br />
=== Tasks Identified ===<br />
<br />
'''Modeling & Structural'''<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (<code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
'''Permission & Behavior'''<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules. Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility. This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
=== Architecture Overview ===<br />
<br />
[[File:Duedate-diagram.png|800px]]<br />
<br />
This diagram visualizes the redesigned architecture with five distinct layers:<br />
<br />
* '''Layer 1 (Blue)''': Parent models (Assignment, SignUpTopic) that own due dates<br />
* '''Layer 2 (Orange)''': DueDateActions module providing action-level queries<br />
* '''Layer 3 (Red)''': DueDate model managing core deadline data<br />
* '''Layer 4 (Orange)''': DueDatePermissions module evaluating permissions<br />
* '''Layer 5 (Green)''': Reference data models (DeadlineType, DeadlineRight, Participant)<br />
<br />
The flow works as follows: Parent models include DueDateActions, which queries DueDate objects. Each DueDate includes DueDatePermissions to evaluate whether actions are allowed based on DeadlineRight states and Participant role flags.<br />
<br />
=== 1. DeadlineType Model ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table. In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
This leads to several structural issues:<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of semantic helper methods (e.g., <code>review?</code>, <code>submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure<br />
|- <br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.deadline_type_id</code><br />
|-<br />
| name || VARCHAR(255) || Unique symbolic name (e.g., <code>submission</code>, <code>review</code>)<br />
|-<br />
| description || TEXT || Human-readable explanation of the deadline category<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries<br />
|-<br />
! ID !! Name !! Description<br />
|-<br />
| 1 || submission || Student submission deadlines<br />
|-<br />
| 2 || review || Peer review deadlines<br />
|-<br />
| 3 || teammate_review || Team member evaluation deadlines<br />
|-<br />
| 5 || metareview || Meta-review deadlines (backward compatibility)<br />
|-<br />
| 6 || drop_topic || Topic drop deadlines<br />
|-<br />
| 7 || signup || Topic signup deadlines<br />
|-<br />
| 8 || team_formation || Team formation deadlines (duplicate cleaned)<br />
|-<br />
| 11 || quiz || Quiz completion deadlines<br />
|}<br />
<br />
=== 2. DeadlineRight Model ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline:<br />
<br />
* '''OK''': Action is allowed without penalty<br />
* '''Late''': Action is allowed but marked as late<br />
* '''No''': Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, and <code>quiz_allowed_id</code>.<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure<br />
|-<br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.*_allowed_id</code> fields<br />
|-<br />
| name || VARCHAR(255) || Unique permission name (<code>No</code>, <code>Late</code>, <code>OK</code>)<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
=== 3. DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating the Single Responsibility Principle. Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Old design: class method that mixes concerns<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is focused on representing a single deadline entry. Behavior has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring<br />
|-<br />
! Concern !! Where It Lives<br />
|-<br />
| Permission checking || <code>DueDatePermissions</code> module (included in DueDate)<br />
|-<br />
| Deadline-related actions || <code>DueDateActions</code> module (included in parent models)<br />
|-<br />
| Deadline type semantics || <code>DeadlineType</code> model<br />
|-<br />
| Core deadline data || <code>DueDate</code> model<br />
|}<br />
<br />
Key improvements:<br />
* '''Instance-based behavior''': Replaced class methods with instance methods<br />
* '''Clear query methods''': Simple predicates like <code>upcoming?</code>, <code>overdue?</code><br />
* '''Scopes for common queries''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code><br />
<br />
=== 4. DueDatePermissions Module ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks are split into two disconnected layers:<br />
<br />
'''Role-based permissions''' (in participant_helpers.rb):<br />
<syntaxhighlight lang="ruby"><br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
# ...<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
'''Deadline-based checks''' (in Assignment model):<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers never interact, leading to inconsistencies.<br />
<br />
==== Proposed Solution ====<br />
<br />
The <code>DueDatePermissions</code> module integrates both layers:<br />
<br />
{| class="wikitable"<br />
|+ Permission Methods<br />
|-<br />
! Method !! What It Checks<br />
|-<br />
| <code>can_submit?(participant)</code> || Submission deadline is OK/Late AND participant can submit<br />
|-<br />
| <code>can_review?(participant)</code> || Review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>can_take_quiz?(participant)</code> || Quiz deadline is OK/Late AND participant can take quiz<br />
|-<br />
| <code>can_review_teammate?(participant)</code> || Teammate review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Generic checker for any activity<br />
|-<br />
| <code>permission_status_for(action)</code> || Returns 'OK', 'Late', or 'No' for display<br />
|}<br />
<br />
=== 5. DueDateActions Module ===<br />
<br />
The <code>DueDateActions</code> module provides a unified interface for models that own due dates (<code>Assignment</code> and <code>SignUpTopic</code>). This centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
==== Purpose ====<br />
<br />
{| class="wikitable"<br />
|+ Methods in DueDateActions<br />
|-<br />
! Method !! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Checks if an activity is permitted at the current time<br />
|-<br />
| <code>submission_permissible?</code> || Convenience wrapper for submission checking<br />
|-<br />
| <code>review_permissible?</code> || Convenience wrapper for review checking<br />
|-<br />
| <code>next_due_date(topic_id)</code> || Resolves the next applicable deadline<br />
|-<br />
| <code>current_stage</code> || Returns human-readable stage name (e.g., "review", "submission")<br />
|-<br />
| <code>has_topic_specific_deadlines?</code> || Determines if assignment uses topic-specific deadlines<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code> || Utility for cloning due dates to another assignment<br />
|}<br />
<br />
==== Deadline Resolution Flow ====<br />
<br />
{| class="wikitable"<br />
|+ How next_due_date Works<br />
|-<br />
! Step !! Description<br />
|-<br />
| 1. Topic-specific check || If topic ID provided and assignment uses staggered deadlines, check topic-level deadlines first<br />
|-<br />
| 2. Assignment-level fallback || If no topic deadline exists, use nearest assignment-level deadline<br />
|-<br />
| 3. Permission evaluation || Delegate to DueDatePermissions to determine if action is allowed<br />
|}<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def next_due_date(topic_id = nil)<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming.first<br />
return topic_deadline if topic_deadline<br />
end<br />
due_dates.upcoming.first<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' — Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' — Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' — Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' — STI subclass for topic-specific deadlines<br />
* '''Assignment''' — Includes DueDateActions mixin<br />
* '''SignUpTopic''' — Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' — Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' — Deadline-related operations for parent models<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the DueDate model using nested contexts, edge case coverage, and error handling.<br />
<br />
=== Current Coverage ===<br />
<br />
* '''Validations''': Required fields (parent, due_at, deadline_type_id), round validation, error messages<br />
* '''Scopes''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code> with edge cases<br />
* '''Instance Methods''': <code>#overdue?</code>, <code>#upcoming?</code>, <code>#set</code>, <code>#copy</code>, <code>#deadline_type_name</code>, <code>#last_deadline?</code>, <code>#<=></code><br />
* '''Class Methods''': <code>.sort_due_dates</code>, <code>.any_future_due_dates?</code>, <code>.copy</code><br />
* '''Callbacks''': <code>before_save :set_default_round</code><br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Planned Future Tests ===<br />
<br />
* '''DueDatePermissions module''': Test <code>can_submit?</code>, <code>can_review?</code>, <code>can_take_quiz?</code> with participant parameters<br />
* '''DueDateActions module''': Test <code>activity_permissible?</code>, <code>next_due_date</code> in Assignment context<br />
* '''Integration tests''': Combined role-based and time-based permission logic<br />
<br />
=== Test Metrics ===<br />
<br />
* '''Total examples''': 438 tests<br />
* '''DueDate model''': 60+ examples<br />
* '''Code coverage''': 100% of DueDate methods<br />
* '''Execution time''': ~12 seconds<br />
<br />
== Demo ==<br />
<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167218
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T15:34:36Z
<p>Skim253: /* Improved Design */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|800px]]<br />
<br />
When editing an assignment, due dates can be modified under the Due Dates tab. Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|800px]]<br />
<br />
In the Assignments tab, the current stage and stage deadline of each assignment is displayed.<br />
<br />
[[File:Due-date-topic-instructor.png|800px]]<br />
<br />
[[File:Due-date-topic-instructor-2.png|800px]]<br />
<br />
In the Topics subtab, due dates for each topic are displayed.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|800px]]<br />
<br />
Students can view due date information under <code>Current State</code> and <code>Stage Deadline</code>. The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|800px]]<br />
<br />
During the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|800px]]<br />
<br />
Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
=== Motivation ===<br />
<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
'''Modeling & Structural Issues'''<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
'''Permission & Behavior Issues'''<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions that combines both role-based and time-based constraints.<br />
<br />
=== Tasks Identified ===<br />
<br />
'''Modeling & Structural'''<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (<code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
'''Permission & Behavior'''<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules. Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility. This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
=== Architecture Overview ===<br />
<br />
[[File:Duedate-diagram.png|800px]]<br />
<br />
This diagram visualizes the redesigned architecture with five distinct layers:<br />
<br />
* '''Layer 1 (Blue)''': Parent models (Assignment, SignUpTopic) that own due dates<br />
* '''Layer 2 (Orange)''': DueDateActions module providing action-level queries<br />
* '''Layer 3 (Red)''': DueDate model managing core deadline data<br />
* '''Layer 4 (Orange)''': DueDatePermissions module evaluating permissions<br />
* '''Layer 5 (Green)''': Reference data models (DeadlineType, DeadlineRight, Participant)<br />
<br />
The flow works as follows: Parent models include DueDateActions, which queries DueDate objects. Each DueDate includes DueDatePermissions to evaluate whether actions are allowed based on DeadlineRight states and Participant role flags.<br />
<br />
=== 1. DeadlineType Model ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table. In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
This leads to several structural issues:<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of semantic helper methods (e.g., <code>review?</code>, <code>submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure<br />
|- <br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.deadline_type_id</code><br />
|-<br />
| name || VARCHAR(255) || Unique symbolic name (e.g., <code>submission</code>, <code>review</code>)<br />
|-<br />
| description || TEXT || Human-readable explanation of the deadline category<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries<br />
|-<br />
! ID !! Name !! Description<br />
|-<br />
| 1 || submission || Student submission deadlines<br />
|-<br />
| 2 || review || Peer review deadlines<br />
|-<br />
| 3 || teammate_review || Team member evaluation deadlines<br />
|-<br />
| 5 || metareview || Meta-review deadlines (backward compatibility)<br />
|-<br />
| 6 || drop_topic || Topic drop deadlines<br />
|-<br />
| 7 || signup || Topic signup deadlines<br />
|-<br />
| 8 || team_formation || Team formation deadlines (duplicate cleaned)<br />
|-<br />
| 11 || quiz || Quiz completion deadlines<br />
|}<br />
<br />
=== 2. DeadlineRight Model ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline:<br />
<br />
* '''OK''': Action is allowed without penalty<br />
* '''Late''': Action is allowed but marked as late<br />
* '''No''': Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, and <code>quiz_allowed_id</code>.<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure<br />
|-<br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.*_allowed_id</code> fields<br />
|-<br />
| name || VARCHAR(255) || Unique permission name (<code>No</code>, <code>Late</code>, <code>OK</code>)<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
=== 3. DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating the Single Responsibility Principle. Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Old design: class method that mixes concerns<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is focused on representing a single deadline entry. Behavior has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring<br />
|-<br />
! Concern !! Where It Lives<br />
|-<br />
| Permission checking || <code>DueDatePermissions</code> module (included in DueDate)<br />
|-<br />
| Deadline-related actions || <code>DueDateActions</code> module (included in parent models)<br />
|-<br />
| Deadline type semantics || <code>DeadlineType</code> model<br />
|-<br />
| Core deadline data || <code>DueDate</code> model<br />
|}<br />
<br />
Key improvements:<br />
* '''Instance-based behavior''': Replaced class methods with instance methods<br />
* '''Clear query methods''': Simple predicates like <code>upcoming?</code>, <code>overdue?</code><br />
* '''Scopes for common queries''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code><br />
<br />
=== 4. DueDatePermissions Module ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks are split into two disconnected layers:<br />
<br />
'''Role-based permissions''' (in participant_helpers.rb):<br />
<syntaxhighlight lang="ruby"><br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
# ...<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
'''Deadline-based checks''' (in Assignment model):<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers never interact, leading to inconsistencies.<br />
<br />
==== Proposed Solution ====<br />
<br />
The <code>DueDatePermissions</code> module integrates both layers:<br />
<br />
{| class="wikitable"<br />
|+ Permission Methods<br />
|-<br />
! Method !! What It Checks<br />
|-<br />
| <code>can_submit?(participant)</code> || Submission deadline is OK/Late AND participant can submit<br />
|-<br />
| <code>can_review?(participant)</code> || Review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>can_take_quiz?(participant)</code> || Quiz deadline is OK/Late AND participant can take quiz<br />
|-<br />
| <code>can_review_teammate?(participant)</code> || Teammate review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Generic checker for any activity<br />
|-<br />
| <code>permission_status_for(action)</code> || Returns 'OK', 'Late', or 'No' for display<br />
|}<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Similar implementations for can_review?, can_take_quiz?, etc.<br />
end<br />
</syntaxhighlight><br />
<br />
=== 5. DueDateActions Module ===<br />
<br />
The <code>DueDateActions</code> module provides a unified interface for models that own due dates (<code>Assignment</code> and <code>SignUpTopic</code>). This centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
==== Purpose ====<br />
<br />
{| class="wikitable"<br />
|+ Methods in DueDateActions<br />
|-<br />
! Method !! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Checks if an activity is permitted at the current time<br />
|-<br />
| <code>submission_permissible?</code> || Convenience wrapper for submission checking<br />
|-<br />
| <code>review_permissible?</code> || Convenience wrapper for review checking<br />
|-<br />
| <code>next_due_date(topic_id)</code> || Resolves the next applicable deadline<br />
|-<br />
| <code>current_stage</code> || Returns human-readable stage name (e.g., "review", "submission")<br />
|-<br />
| <code>has_topic_specific_deadlines?</code> || Determines if assignment uses topic-specific deadlines<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code> || Utility for cloning due dates to another assignment<br />
|}<br />
<br />
==== Deadline Resolution Flow ====<br />
<br />
{| class="wikitable"<br />
|+ How next_due_date Works<br />
|-<br />
! Step !! Description<br />
|-<br />
| 1. Topic-specific check || If topic ID provided and assignment uses staggered deadlines, check topic-level deadlines first<br />
|-<br />
| 2. Assignment-level fallback || If no topic deadline exists, use nearest assignment-level deadline<br />
|-<br />
| 3. Permission evaluation || Delegate to DueDatePermissions to determine if action is allowed<br />
|}<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def next_due_date(topic_id = nil)<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming.first<br />
return topic_deadline if topic_deadline<br />
end<br />
due_dates.upcoming.first<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' — Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' — Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' — Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' — STI subclass for topic-specific deadlines<br />
* '''Assignment''' — Includes DueDateActions mixin<br />
* '''SignUpTopic''' — Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' — Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' — Deadline-related operations for parent models<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the DueDate model using nested contexts, edge case coverage, and error handling.<br />
<br />
=== Current Coverage ===<br />
<br />
* '''Validations''': Required fields (parent, due_at, deadline_type_id), round validation, error messages<br />
* '''Scopes''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code> with edge cases<br />
* '''Instance Methods''': <code>#overdue?</code>, <code>#upcoming?</code>, <code>#set</code>, <code>#copy</code>, <code>#deadline_type_name</code>, <code>#last_deadline?</code>, <code>#<=></code><br />
* '''Class Methods''': <code>.sort_due_dates</code>, <code>.any_future_due_dates?</code>, <code>.copy</code><br />
* '''Callbacks''': <code>before_save :set_default_round</code><br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Planned Future Tests ===<br />
<br />
* '''DueDatePermissions module''': Test <code>can_submit?</code>, <code>can_review?</code>, <code>can_take_quiz?</code> with participant parameters<br />
* '''DueDateActions module''': Test <code>activity_permissible?</code>, <code>next_due_date</code> in Assignment context<br />
* '''Integration tests''': Combined role-based and time-based permission logic<br />
<br />
=== Test Metrics ===<br />
<br />
* '''Total examples''': 438 tests<br />
* '''DueDate model''': 60+ examples<br />
* '''Code coverage''': 100% of DueDate methods<br />
* '''Execution time''': ~12 seconds<br />
<br />
== Demo ==<br />
<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167217
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T15:34:10Z
<p>Skim253: /* 2. DeadlineRight Model */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|800px]]<br />
<br />
When editing an assignment, due dates can be modified under the Due Dates tab. Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|800px]]<br />
<br />
In the Assignments tab, the current stage and stage deadline of each assignment is displayed.<br />
<br />
[[File:Due-date-topic-instructor.png|800px]]<br />
<br />
[[File:Due-date-topic-instructor-2.png|800px]]<br />
<br />
In the Topics subtab, due dates for each topic are displayed.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|800px]]<br />
<br />
Students can view due date information under <code>Current State</code> and <code>Stage Deadline</code>. The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|800px]]<br />
<br />
During the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|800px]]<br />
<br />
Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
=== Motivation ===<br />
<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
'''Modeling & Structural Issues'''<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
'''Permission & Behavior Issues'''<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions that combines both role-based and time-based constraints.<br />
<br />
=== Tasks Identified ===<br />
<br />
'''Modeling & Structural'''<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (<code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
'''Permission & Behavior'''<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules. Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility. This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
=== Architecture Overview ===<br />
<br />
[[File:Duedate-diagram.png|800px]]<br />
<br />
This diagram visualizes the redesigned architecture with five distinct layers:<br />
<br />
* '''Layer 1 (Blue)''': Parent models (Assignment, SignUpTopic) that own due dates<br />
* '''Layer 2 (Orange)''': DueDateActions module providing action-level queries<br />
* '''Layer 3 (Red)''': DueDate model managing core deadline data<br />
* '''Layer 4 (Orange)''': DueDatePermissions module evaluating permissions<br />
* '''Layer 5 (Green)''': Reference data models (DeadlineType, DeadlineRight, Participant)<br />
<br />
The flow works as follows: Parent models include DueDateActions, which queries DueDate objects. Each DueDate includes DueDatePermissions to evaluate whether actions are allowed based on DeadlineRight states and Participant role flags.<br />
<br />
=== 1. DeadlineType Model ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table. In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
This leads to several structural issues:<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of semantic helper methods (e.g., <code>review?</code>, <code>submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure<br />
|- <br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.deadline_type_id</code><br />
|-<br />
| name || VARCHAR(255) || Unique symbolic name (e.g., <code>submission</code>, <code>review</code>)<br />
|-<br />
| description || TEXT || Human-readable explanation of the deadline category<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries<br />
|-<br />
! ID !! Name !! Description<br />
|-<br />
| 1 || submission || Student submission deadlines<br />
|-<br />
| 2 || review || Peer review deadlines<br />
|-<br />
| 3 || teammate_review || Team member evaluation deadlines<br />
|-<br />
| 5 || metareview || Meta-review deadlines (backward compatibility)<br />
|-<br />
| 6 || drop_topic || Topic drop deadlines<br />
|-<br />
| 7 || signup || Topic signup deadlines<br />
|-<br />
| 8 || team_formation || Team formation deadlines (duplicate cleaned)<br />
|-<br />
| 11 || quiz || Quiz completion deadlines<br />
|}<br />
<br />
=== 2. DeadlineRight Model ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline:<br />
<br />
* '''OK''': Action is allowed without penalty<br />
* '''Late''': Action is allowed but marked as late<br />
* '''No''': Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, and <code>quiz_allowed_id</code>.<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure<br />
|-<br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.*_allowed_id</code> fields<br />
|-<br />
| name || VARCHAR(255) || Unique permission name (<code>No</code>, <code>Late</code>, <code>OK</code>)<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
=== 3. DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating the Single Responsibility Principle. Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Old design: class method that mixes concerns<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is focused on representing a single deadline entry. Behavior has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring<br />
|-<br />
! Concern !! Where It Lives<br />
|-<br />
| Permission checking || <code>DueDatePermissions</code> module (included in DueDate)<br />
|-<br />
| Deadline-related actions || <code>DueDateActions</code> module (included in parent models)<br />
|-<br />
| Deadline type semantics || <code>DeadlineType</code> model<br />
|-<br />
| Core deadline data || <code>DueDate</code> model<br />
|}<br />
<br />
Key improvements:<br />
* '''Instance-based behavior''': Replaced class methods with instance methods<br />
* '''Clear query methods''': Simple predicates like <code>upcoming?</code>, <code>overdue?</code><br />
* '''Scopes for common queries''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code><br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type<br />
validates :due_at, :deadline_type_id, :parent, presence: true<br />
<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
def copy(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = Assignment.find(to_assignment_id)<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== 4. DueDatePermissions Module ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks are split into two disconnected layers:<br />
<br />
'''Role-based permissions''' (in participant_helpers.rb):<br />
<syntaxhighlight lang="ruby"><br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
# ...<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
'''Deadline-based checks''' (in Assignment model):<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers never interact, leading to inconsistencies.<br />
<br />
==== Proposed Solution ====<br />
<br />
The <code>DueDatePermissions</code> module integrates both layers:<br />
<br />
{| class="wikitable"<br />
|+ Permission Methods<br />
|-<br />
! Method !! What It Checks<br />
|-<br />
| <code>can_submit?(participant)</code> || Submission deadline is OK/Late AND participant can submit<br />
|-<br />
| <code>can_review?(participant)</code> || Review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>can_take_quiz?(participant)</code> || Quiz deadline is OK/Late AND participant can take quiz<br />
|-<br />
| <code>can_review_teammate?(participant)</code> || Teammate review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Generic checker for any activity<br />
|-<br />
| <code>permission_status_for(action)</code> || Returns 'OK', 'Late', or 'No' for display<br />
|}<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Similar implementations for can_review?, can_take_quiz?, etc.<br />
end<br />
</syntaxhighlight><br />
<br />
=== 5. DueDateActions Module ===<br />
<br />
The <code>DueDateActions</code> module provides a unified interface for models that own due dates (<code>Assignment</code> and <code>SignUpTopic</code>). This centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
==== Purpose ====<br />
<br />
{| class="wikitable"<br />
|+ Methods in DueDateActions<br />
|-<br />
! Method !! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Checks if an activity is permitted at the current time<br />
|-<br />
| <code>submission_permissible?</code> || Convenience wrapper for submission checking<br />
|-<br />
| <code>review_permissible?</code> || Convenience wrapper for review checking<br />
|-<br />
| <code>next_due_date(topic_id)</code> || Resolves the next applicable deadline<br />
|-<br />
| <code>current_stage</code> || Returns human-readable stage name (e.g., "review", "submission")<br />
|-<br />
| <code>has_topic_specific_deadlines?</code> || Determines if assignment uses topic-specific deadlines<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code> || Utility for cloning due dates to another assignment<br />
|}<br />
<br />
==== Deadline Resolution Flow ====<br />
<br />
{| class="wikitable"<br />
|+ How next_due_date Works<br />
|-<br />
! Step !! Description<br />
|-<br />
| 1. Topic-specific check || If topic ID provided and assignment uses staggered deadlines, check topic-level deadlines first<br />
|-<br />
| 2. Assignment-level fallback || If no topic deadline exists, use nearest assignment-level deadline<br />
|-<br />
| 3. Permission evaluation || Delegate to DueDatePermissions to determine if action is allowed<br />
|}<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def next_due_date(topic_id = nil)<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming.first<br />
return topic_deadline if topic_deadline<br />
end<br />
due_dates.upcoming.first<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' — Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' — Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' — Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' — STI subclass for topic-specific deadlines<br />
* '''Assignment''' — Includes DueDateActions mixin<br />
* '''SignUpTopic''' — Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' — Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' — Deadline-related operations for parent models<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the DueDate model using nested contexts, edge case coverage, and error handling.<br />
<br />
=== Current Coverage ===<br />
<br />
* '''Validations''': Required fields (parent, due_at, deadline_type_id), round validation, error messages<br />
* '''Scopes''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code> with edge cases<br />
* '''Instance Methods''': <code>#overdue?</code>, <code>#upcoming?</code>, <code>#set</code>, <code>#copy</code>, <code>#deadline_type_name</code>, <code>#last_deadline?</code>, <code>#<=></code><br />
* '''Class Methods''': <code>.sort_due_dates</code>, <code>.any_future_due_dates?</code>, <code>.copy</code><br />
* '''Callbacks''': <code>before_save :set_default_round</code><br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Planned Future Tests ===<br />
<br />
* '''DueDatePermissions module''': Test <code>can_submit?</code>, <code>can_review?</code>, <code>can_take_quiz?</code> with participant parameters<br />
* '''DueDateActions module''': Test <code>activity_permissible?</code>, <code>next_due_date</code> in Assignment context<br />
* '''Integration tests''': Combined role-based and time-based permission logic<br />
<br />
=== Test Metrics ===<br />
<br />
* '''Total examples''': 438 tests<br />
* '''DueDate model''': 60+ examples<br />
* '''Code coverage''': 100% of DueDate methods<br />
* '''Execution time''': ~12 seconds<br />
<br />
== Demo ==<br />
<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167216
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T15:33:14Z
<p>Skim253: /* 1. DeadlineType Model */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|800px]]<br />
<br />
When editing an assignment, due dates can be modified under the Due Dates tab. Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|800px]]<br />
<br />
In the Assignments tab, the current stage and stage deadline of each assignment is displayed.<br />
<br />
[[File:Due-date-topic-instructor.png|800px]]<br />
<br />
[[File:Due-date-topic-instructor-2.png|800px]]<br />
<br />
In the Topics subtab, due dates for each topic are displayed.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|800px]]<br />
<br />
Students can view due date information under <code>Current State</code> and <code>Stage Deadline</code>. The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|800px]]<br />
<br />
During the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|800px]]<br />
<br />
Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
=== Motivation ===<br />
<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
'''Modeling & Structural Issues'''<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
'''Permission & Behavior Issues'''<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions that combines both role-based and time-based constraints.<br />
<br />
=== Tasks Identified ===<br />
<br />
'''Modeling & Structural'''<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (<code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
'''Permission & Behavior'''<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules. Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility. This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
=== Architecture Overview ===<br />
<br />
[[File:Duedate-diagram.png|800px]]<br />
<br />
This diagram visualizes the redesigned architecture with five distinct layers:<br />
<br />
* '''Layer 1 (Blue)''': Parent models (Assignment, SignUpTopic) that own due dates<br />
* '''Layer 2 (Orange)''': DueDateActions module providing action-level queries<br />
* '''Layer 3 (Red)''': DueDate model managing core deadline data<br />
* '''Layer 4 (Orange)''': DueDatePermissions module evaluating permissions<br />
* '''Layer 5 (Green)''': Reference data models (DeadlineType, DeadlineRight, Participant)<br />
<br />
The flow works as follows: Parent models include DueDateActions, which queries DueDate objects. Each DueDate includes DueDatePermissions to evaluate whether actions are allowed based on DeadlineRight states and Participant role flags.<br />
<br />
=== 1. DeadlineType Model ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table. In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
This leads to several structural issues:<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of semantic helper methods (e.g., <code>review?</code>, <code>submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure<br />
|- <br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.deadline_type_id</code><br />
|-<br />
| name || VARCHAR(255) || Unique symbolic name (e.g., <code>submission</code>, <code>review</code>)<br />
|-<br />
| description || TEXT || Human-readable explanation of the deadline category<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries<br />
|-<br />
! ID !! Name !! Description<br />
|-<br />
| 1 || submission || Student submission deadlines<br />
|-<br />
| 2 || review || Peer review deadlines<br />
|-<br />
| 3 || teammate_review || Team member evaluation deadlines<br />
|-<br />
| 5 || metareview || Meta-review deadlines (backward compatibility)<br />
|-<br />
| 6 || drop_topic || Topic drop deadlines<br />
|-<br />
| 7 || signup || Topic signup deadlines<br />
|-<br />
| 8 || team_formation || Team formation deadlines (duplicate cleaned)<br />
|-<br />
| 11 || quiz || Quiz completion deadlines<br />
|}<br />
<br />
=== 2. DeadlineRight Model ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline:<br />
<br />
* '''OK''': Action is allowed without penalty<br />
* '''Late''': Action is allowed but marked as late<br />
* '''No''': Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, and <code>quiz_allowed_id</code>.<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure<br />
|-<br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.*_allowed_id</code> fields<br />
|-<br />
| name || VARCHAR(255) || Unique permission name (<code>No</code>, <code>Late</code>, <code>OK</code>)<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
==== Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== 3. DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating the Single Responsibility Principle. Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Old design: class method that mixes concerns<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is focused on representing a single deadline entry. Behavior has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring<br />
|-<br />
! Concern !! Where It Lives<br />
|-<br />
| Permission checking || <code>DueDatePermissions</code> module (included in DueDate)<br />
|-<br />
| Deadline-related actions || <code>DueDateActions</code> module (included in parent models)<br />
|-<br />
| Deadline type semantics || <code>DeadlineType</code> model<br />
|-<br />
| Core deadline data || <code>DueDate</code> model<br />
|}<br />
<br />
Key improvements:<br />
* '''Instance-based behavior''': Replaced class methods with instance methods<br />
* '''Clear query methods''': Simple predicates like <code>upcoming?</code>, <code>overdue?</code><br />
* '''Scopes for common queries''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code><br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type<br />
validates :due_at, :deadline_type_id, :parent, presence: true<br />
<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
def copy(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = Assignment.find(to_assignment_id)<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== 4. DueDatePermissions Module ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks are split into two disconnected layers:<br />
<br />
'''Role-based permissions''' (in participant_helpers.rb):<br />
<syntaxhighlight lang="ruby"><br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
# ...<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
'''Deadline-based checks''' (in Assignment model):<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers never interact, leading to inconsistencies.<br />
<br />
==== Proposed Solution ====<br />
<br />
The <code>DueDatePermissions</code> module integrates both layers:<br />
<br />
{| class="wikitable"<br />
|+ Permission Methods<br />
|-<br />
! Method !! What It Checks<br />
|-<br />
| <code>can_submit?(participant)</code> || Submission deadline is OK/Late AND participant can submit<br />
|-<br />
| <code>can_review?(participant)</code> || Review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>can_take_quiz?(participant)</code> || Quiz deadline is OK/Late AND participant can take quiz<br />
|-<br />
| <code>can_review_teammate?(participant)</code> || Teammate review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Generic checker for any activity<br />
|-<br />
| <code>permission_status_for(action)</code> || Returns 'OK', 'Late', or 'No' for display<br />
|}<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Similar implementations for can_review?, can_take_quiz?, etc.<br />
end<br />
</syntaxhighlight><br />
<br />
=== 5. DueDateActions Module ===<br />
<br />
The <code>DueDateActions</code> module provides a unified interface for models that own due dates (<code>Assignment</code> and <code>SignUpTopic</code>). This centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
==== Purpose ====<br />
<br />
{| class="wikitable"<br />
|+ Methods in DueDateActions<br />
|-<br />
! Method !! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Checks if an activity is permitted at the current time<br />
|-<br />
| <code>submission_permissible?</code> || Convenience wrapper for submission checking<br />
|-<br />
| <code>review_permissible?</code> || Convenience wrapper for review checking<br />
|-<br />
| <code>next_due_date(topic_id)</code> || Resolves the next applicable deadline<br />
|-<br />
| <code>current_stage</code> || Returns human-readable stage name (e.g., "review", "submission")<br />
|-<br />
| <code>has_topic_specific_deadlines?</code> || Determines if assignment uses topic-specific deadlines<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code> || Utility for cloning due dates to another assignment<br />
|}<br />
<br />
==== Deadline Resolution Flow ====<br />
<br />
{| class="wikitable"<br />
|+ How next_due_date Works<br />
|-<br />
! Step !! Description<br />
|-<br />
| 1. Topic-specific check || If topic ID provided and assignment uses staggered deadlines, check topic-level deadlines first<br />
|-<br />
| 2. Assignment-level fallback || If no topic deadline exists, use nearest assignment-level deadline<br />
|-<br />
| 3. Permission evaluation || Delegate to DueDatePermissions to determine if action is allowed<br />
|}<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def next_due_date(topic_id = nil)<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming.first<br />
return topic_deadline if topic_deadline<br />
end<br />
due_dates.upcoming.first<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' — Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' — Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' — Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' — STI subclass for topic-specific deadlines<br />
* '''Assignment''' — Includes DueDateActions mixin<br />
* '''SignUpTopic''' — Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' — Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' — Deadline-related operations for parent models<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the DueDate model using nested contexts, edge case coverage, and error handling.<br />
<br />
=== Current Coverage ===<br />
<br />
* '''Validations''': Required fields (parent, due_at, deadline_type_id), round validation, error messages<br />
* '''Scopes''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code> with edge cases<br />
* '''Instance Methods''': <code>#overdue?</code>, <code>#upcoming?</code>, <code>#set</code>, <code>#copy</code>, <code>#deadline_type_name</code>, <code>#last_deadline?</code>, <code>#<=></code><br />
* '''Class Methods''': <code>.sort_due_dates</code>, <code>.any_future_due_dates?</code>, <code>.copy</code><br />
* '''Callbacks''': <code>before_save :set_default_round</code><br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Planned Future Tests ===<br />
<br />
* '''DueDatePermissions module''': Test <code>can_submit?</code>, <code>can_review?</code>, <code>can_take_quiz?</code> with participant parameters<br />
* '''DueDateActions module''': Test <code>activity_permissible?</code>, <code>next_due_date</code> in Assignment context<br />
* '''Integration tests''': Combined role-based and time-based permission logic<br />
<br />
=== Test Metrics ===<br />
<br />
* '''Total examples''': 438 tests<br />
* '''DueDate model''': 60+ examples<br />
* '''Code coverage''': 100% of DueDate methods<br />
* '''Execution time''': ~12 seconds<br />
<br />
== Demo ==<br />
<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167215
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T15:31:48Z
<p>Skim253: </p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|800px]]<br />
<br />
When editing an assignment, due dates can be modified under the Due Dates tab. Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|800px]]<br />
<br />
In the Assignments tab, the current stage and stage deadline of each assignment is displayed.<br />
<br />
[[File:Due-date-topic-instructor.png|800px]]<br />
<br />
[[File:Due-date-topic-instructor-2.png|800px]]<br />
<br />
In the Topics subtab, due dates for each topic are displayed.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|800px]]<br />
<br />
Students can view due date information under <code>Current State</code> and <code>Stage Deadline</code>. The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|800px]]<br />
<br />
During the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|800px]]<br />
<br />
Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
=== Motivation ===<br />
<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
'''Modeling & Structural Issues'''<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
'''Permission & Behavior Issues'''<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions that combines both role-based and time-based constraints.<br />
<br />
=== Tasks Identified ===<br />
<br />
'''Modeling & Structural'''<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (<code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
'''Permission & Behavior'''<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules. Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility. This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
=== Architecture Overview ===<br />
<br />
[[File:Duedate-diagram.png|800px]]<br />
<br />
This diagram visualizes the redesigned architecture with five distinct layers:<br />
<br />
* '''Layer 1 (Blue)''': Parent models (Assignment, SignUpTopic) that own due dates<br />
* '''Layer 2 (Orange)''': DueDateActions module providing action-level queries<br />
* '''Layer 3 (Red)''': DueDate model managing core deadline data<br />
* '''Layer 4 (Orange)''': DueDatePermissions module evaluating permissions<br />
* '''Layer 5 (Green)''': Reference data models (DeadlineType, DeadlineRight, Participant)<br />
<br />
The flow works as follows: Parent models include DueDateActions, which queries DueDate objects. Each DueDate includes DueDatePermissions to evaluate whether actions are allowed based on DeadlineRight states and Participant role flags.<br />
<br />
=== 1. DeadlineType Model ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table. In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
This leads to several structural issues:<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of semantic helper methods (e.g., <code>review?</code>, <code>submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure<br />
|- <br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.deadline_type_id</code><br />
|-<br />
| name || VARCHAR(255) || Unique symbolic name (e.g., <code>submission</code>, <code>review</code>)<br />
|-<br />
| description || TEXT || Human-readable explanation of the deadline category<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries<br />
|-<br />
! ID !! Name !! Description<br />
|-<br />
| 1 || submission || Student submission deadlines<br />
|-<br />
| 2 || review || Peer review deadlines<br />
|-<br />
| 3 || teammate_review || Team member evaluation deadlines<br />
|-<br />
| 5 || metareview || Meta-review deadlines (backward compatibility)<br />
|-<br />
| 6 || drop_topic || Topic drop deadlines<br />
|-<br />
| 7 || signup || Topic signup deadlines<br />
|-<br />
| 8 || team_formation || Team formation deadlines (duplicate cleaned)<br />
|-<br />
| 11 || quiz || Quiz completion deadlines<br />
|}<br />
<br />
==== Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods<br />
def submission?<br />
name == 'submission'<br />
end<br />
<br />
def review?<br />
name == 'review'<br />
end<br />
<br />
# Additional helpers: teammate_review?, quiz?, team_formation?, signup?, drop_topic?<br />
end<br />
</syntaxhighlight><br />
<br />
=== 2. DeadlineRight Model ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline:<br />
<br />
* '''OK''': Action is allowed without penalty<br />
* '''Late''': Action is allowed but marked as late<br />
* '''No''': Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, and <code>quiz_allowed_id</code>.<br />
<br />
==== Database Schema ====<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure<br />
|-<br />
! Column !! Type !! Description<br />
|-<br />
| id || BIGINT || Primary key, referenced by <code>due_dates.*_allowed_id</code> fields<br />
|-<br />
| name || VARCHAR(255) || Unique permission name (<code>No</code>, <code>Late</code>, <code>OK</code>)<br />
|-<br />
| created_at || TIMESTAMP || Creation timestamp<br />
|-<br />
| updated_at || TIMESTAMP || Last update timestamp<br />
|}<br />
<br />
==== Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== 3. DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating the Single Responsibility Principle. Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Old design: class method that mixes concerns<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is focused on representing a single deadline entry. Behavior has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring<br />
|-<br />
! Concern !! Where It Lives<br />
|-<br />
| Permission checking || <code>DueDatePermissions</code> module (included in DueDate)<br />
|-<br />
| Deadline-related actions || <code>DueDateActions</code> module (included in parent models)<br />
|-<br />
| Deadline type semantics || <code>DeadlineType</code> model<br />
|-<br />
| Core deadline data || <code>DueDate</code> model<br />
|}<br />
<br />
Key improvements:<br />
* '''Instance-based behavior''': Replaced class methods with instance methods<br />
* '''Clear query methods''': Simple predicates like <code>upcoming?</code>, <code>overdue?</code><br />
* '''Scopes for common queries''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code><br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type<br />
validates :due_at, :deadline_type_id, :parent, presence: true<br />
<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
def copy(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = Assignment.find(to_assignment_id)<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== 4. DueDatePermissions Module ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks are split into two disconnected layers:<br />
<br />
'''Role-based permissions''' (in participant_helpers.rb):<br />
<syntaxhighlight lang="ruby"><br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
# ...<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
'''Deadline-based checks''' (in Assignment model):<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers never interact, leading to inconsistencies.<br />
<br />
==== Proposed Solution ====<br />
<br />
The <code>DueDatePermissions</code> module integrates both layers:<br />
<br />
{| class="wikitable"<br />
|+ Permission Methods<br />
|-<br />
! Method !! What It Checks<br />
|-<br />
| <code>can_submit?(participant)</code> || Submission deadline is OK/Late AND participant can submit<br />
|-<br />
| <code>can_review?(participant)</code> || Review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>can_take_quiz?(participant)</code> || Quiz deadline is OK/Late AND participant can take quiz<br />
|-<br />
| <code>can_review_teammate?(participant)</code> || Teammate review deadline is OK/Late AND participant can review<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Generic checker for any activity<br />
|-<br />
| <code>permission_status_for(action)</code> || Returns 'OK', 'Late', or 'No' for display<br />
|}<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Similar implementations for can_review?, can_take_quiz?, etc.<br />
end<br />
</syntaxhighlight><br />
<br />
=== 5. DueDateActions Module ===<br />
<br />
The <code>DueDateActions</code> module provides a unified interface for models that own due dates (<code>Assignment</code> and <code>SignUpTopic</code>). This centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
==== Purpose ====<br />
<br />
{| class="wikitable"<br />
|+ Methods in DueDateActions<br />
|-<br />
! Method !! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code> || Checks if an activity is permitted at the current time<br />
|-<br />
| <code>submission_permissible?</code> || Convenience wrapper for submission checking<br />
|-<br />
| <code>review_permissible?</code> || Convenience wrapper for review checking<br />
|-<br />
| <code>next_due_date(topic_id)</code> || Resolves the next applicable deadline<br />
|-<br />
| <code>current_stage</code> || Returns human-readable stage name (e.g., "review", "submission")<br />
|-<br />
| <code>has_topic_specific_deadlines?</code> || Determines if assignment uses topic-specific deadlines<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code> || Utility for cloning due dates to another assignment<br />
|}<br />
<br />
==== Deadline Resolution Flow ====<br />
<br />
{| class="wikitable"<br />
|+ How next_due_date Works<br />
|-<br />
! Step !! Description<br />
|-<br />
| 1. Topic-specific check || If topic ID provided and assignment uses staggered deadlines, check topic-level deadlines first<br />
|-<br />
| 2. Assignment-level fallback || If no topic deadline exists, use nearest assignment-level deadline<br />
|-<br />
| 3. Permission evaluation || Delegate to DueDatePermissions to determine if action is allowed<br />
|}<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def next_due_date(topic_id = nil)<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming.first<br />
return topic_deadline if topic_deadline<br />
end<br />
due_dates.upcoming.first<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' — Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' — Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' — Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' — STI subclass for topic-specific deadlines<br />
* '''Assignment''' — Includes DueDateActions mixin<br />
* '''SignUpTopic''' — Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' — Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' — Deadline-related operations for parent models<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the DueDate model using nested contexts, edge case coverage, and error handling.<br />
<br />
=== Current Coverage ===<br />
<br />
* '''Validations''': Required fields (parent, due_at, deadline_type_id), round validation, error messages<br />
* '''Scopes''': <code>.upcoming</code>, <code>.overdue</code>, <code>.for_round</code>, <code>.for_deadline_type</code> with edge cases<br />
* '''Instance Methods''': <code>#overdue?</code>, <code>#upcoming?</code>, <code>#set</code>, <code>#copy</code>, <code>#deadline_type_name</code>, <code>#last_deadline?</code>, <code>#<=></code><br />
* '''Class Methods''': <code>.sort_due_dates</code>, <code>.any_future_due_dates?</code>, <code>.copy</code><br />
* '''Callbacks''': <code>before_save :set_default_round</code><br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Planned Future Tests ===<br />
<br />
* '''DueDatePermissions module''': Test <code>can_submit?</code>, <code>can_review?</code>, <code>can_take_quiz?</code> with participant parameters<br />
* '''DueDateActions module''': Test <code>activity_permissible?</code>, <code>next_due_date</code> in Assignment context<br />
* '''Integration tests''': Combined role-based and time-based permission logic<br />
<br />
=== Test Metrics ===<br />
<br />
* '''Total examples''': 438 tests<br />
* '''DueDate model''': 60+ examples<br />
* '''Code coverage''': 100% of DueDate methods<br />
* '''Execution time''': ~12 seconds<br />
<br />
== Demo ==<br />
<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167208
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T05:24:23Z
<p>Skim253: </p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Instructor's View====<br />
[[File:Duedates.png|800px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|800px]]<br />
<br />
* In the Assignments tab, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
[[File:Due-date-topic-instructor.png|800px]]<br />
<br />
[[File:Due-date-topic-instructor-2.png|800px]]<br />
<br />
* In the Topics subtab, the ''DueDate'' of each topics are displayed.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|800px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|800px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|800px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules.<br />
Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility.<br />
This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
<br />
[[File:Duedate-diagram.png|800px]]<br />
<br />
This diagram visualizes the redesigned architecture: blue/red/green indicate Rails models, orange indicates modules. <br />
Parent models call DueDateActions, which manages DueDate, while DueDatePermissions checks user rights using reference models. <br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<br />
The <code>deadline_types</code> table defines all canonical deadline categories used by the system.<br />
Each row represents one distinct deadline type, and every <code>DueDate</code> record must reference one of these entries through <code>deadline_type_id</code>.<br />
<br />
Below is a structural description of the table:<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure <br />
|- <br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each deadline type; referenced by <code>due_dates.deadline_type_id</code>. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic name (e.g., <code>submission</code>, <code>review</code>); must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of the deadline category. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Time when the row was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Time when the row was last updated. <br />
|} <br />
<br />
This schema ensures that:<br />
<br />
* Each deadline type has a unique name and description.<br />
* No duplicate entries can exist (e.g., the prior duplicated <code>team_formation</code> was cleaned).<br />
* All <code>DueDate</code> rows reference this master table through <code>deadline_type_id</code>.<br />
* The <code>id</code> column acts as the authoritative key used throughout permissions and due-date logic.<br />
<br />
Migrated constraints also ensure that <code>due_dates.deadline_type_id</code> is consistently stored as <code>BIGINT</code>, allowing a long-term stable keyspace.<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
Because each row in <code>deadline_types</code> is referenced by <code>DueDate.deadline_type_id</code>, the following definitions map directly to the schema above.<br />
<br />
Each ID corresponds exactly to the <code>id</code> field in the table and serves as the system-wide canonical reference for that deadline category.<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries <br />
|-<br />
! ID <br />
! Name <br />
! Description <br />
|- <br />
| 1 <br />
| submission <br />
| Student submission deadlines <br />
|- <br />
| 2 <br />
| review <br />
| Peer review deadlines <br />
|- <br />
| 3 <br />
| teammate_review <br />
| Team member evaluation deadlines <br />
|- <br />
| 5 <br />
| metareview <br />
| Meta-review deadlines (kept for backward compatibility) <br />
|- <br />
| 6 <br />
| drop_topic <br />
| Topic drop deadlines <br />
|- <br />
| 7 <br />
| signup <br />
| Topic signup deadlines <br />
|- <br />
| 8 <br />
| team_formation <br />
| Team formation deadlines (duplicate entries cleaned; ID 8 is canonical) <br />
|- <br />
| 11 <br />
| quiz <br />
| Quiz completion deadlines <br />
|} <br />
<br />
These definitions are seeded during migration and act as the source of truth for all deadline-related logic within <code>DueDate</code>, <code>DueDatePermissions</code>, and <code>DueDateActions</code>.<br />
By linking each <code>DueDate</code> to one of these entries through <code>deadline_type_id</code>, the system standardizes behavior and eliminates inconsistent ID or string comparisons from earlier implementations.<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <br />
* <code>OK</code> : Action is allowed without penalty<br />
* <code>Late</code> : Action is allowed but marked as late<br />
* <code>No</code> : Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, <code>quiz_allowed_id</code>, and others.<br />
This allows the system to determine user permissions by combining:<br />
<br />
# The current deadline’s allowed state<br />
# The participant’s role-based ability (submit, review, take quiz)<br />
<br />
This combination logic is implemented in <code>DueDatePermissions</code>.<br />
<br />
==== Database Schema ====<br />
The <code>deadline_rights</code> table stores the canonical permission states used across the entire due-date system.<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure <br />
|-<br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each permission state. Referenced by <code>due_dates.*_allowed_id</code> fields. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic permission name (<code>No</code>, <code>Late</code>, <code>OK</code>). Must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of what the permission state means. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was last updated. <br />
|} <br />
<br />
==== DeadlineRight Model ====<br />
Instead of embedding permission logic inside <code>DueDate</code>, the <code>DeadlineRight</code> model defines the meaning of each permission state.<br />
This removes magic strings (<code>"OK"</code>) and numeric comparisons and replaces them with expressive model-level semantics.<br />
<br />
{| class="wikitable"<br />
|+ Semantic Meaning Provided by <code>DeadlineRight</code> <br />
|-<br />
! Concept <br />
! Meaning <br />
|- <br />
| allows_action? <br />
| True for <code>OK</code> or <code>Late</code>; false for <code>No</code>. <br />
|- <br />
| denies_action? <br />
| True only for <code>No</code>. <br />
|- <br />
| allows_with_penalty? <br />
| True only for <code>Late</code>. <br />
|- <br />
| allows_without_penalty? <br />
| True only for <code>OK</code>. <br />
|- <br />
| permission_level <br />
| Numeric ordering: No = 0, Late = 1, OK = 2. Used for comparison and sorting. <br />
|} <br />
<br />
These behaviors allow other parts of the system—particularly <code>DueDatePermissions</code>—to make consistent, readable decisions.<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is simpler, more modular, and focused on representing a single deadline entry.<br />
Behavior previously embedded inside <code>DueDate</code> has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring <br />
|-<br />
! Concern <br />
! Where It Lives Now <br />
|- <br />
| Permission checking <br />
| <code>DueDatePermissions</code> module <br />
|- <br />
| Deadline-related actions (next deadline, stage name, deadline copying) <br />
| <code>DueDateActions</code> module (included in parent models) <br />
|- <br />
| Deadline type semantics <br />
| <code>DeadlineType</code> model <br />
|- <br />
| Core deadline data (due_at, round, parent) <br />
| <code>DueDate</code> model <br />
|} <br />
<br />
===== Instance-Based Behavior Instead of Class Methods =====<br />
<br />
Previously, many behaviors were class methods (e.g., copying deadlines).<br />
These methods did not reflect object-level behavior and often duplicated logic.<br />
<br />
The redesign moves these operations to:<br />
<br />
* instance methods for actions on a specific <code>DueDate</code><br />
* modules (DueDateActions) for higher-level behaviors on assignments or topics<br />
<br />
This separation:<br />
<br />
* improves testability<br />
* aligns with Rails conventions<br />
* avoids state duplication<br />
<br />
===== Clearer Query Methods =====<br />
<br />
The model now exposes simple, intuitive instance-level questions:<br />
<br />
{| class="wikitable"<br />
|+ Examples of Simplified State Queries <br />
|-<br />
! Method <br />
! Meaning <br />
|- <br />
| <code>upcoming?</code> <br />
| Whether the deadline occurs in the future <br />
|- <br />
| <code>overdue?</code> <br />
| Whether the deadline has already passed <br />
|- <br />
| <code>deadline_type_name</code> <br />
| Human-readable deadline type <br />
|} <br />
<br />
These small, composable predicates replace multiple ad-hoc comparisons scattered across the codebase.<br />
<br />
=== DueDatePermissions Mixin ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks.<br />
Instead of embedding checks directly into <code>Assignment</code> or <code>DueDate</code>, all permission logic now flows through <code>DueDatePermissions</code>.<br />
<br />
{| class="wikitable"<br />
|+ Meaning of Permission Methods <br />
! Method <br />
! What It Determines <br />
|- <br />
| can_submit? <br />
| Submission is allowed only if (1) the submission deadline is OK/Late and (2) the participant’s role permits submitting. <br />
|- <br />
| can_review? <br />
| Review is allowed only if the review deadline is OK/Late and the participant has review privileges. <br />
|- <br />
| can_take_quiz? <br />
| Quiz access is controlled by both quiz deadlines and participant quiz permissions. <br />
|- <br />
| can_review_teammate? <br />
| Teammate review uses both the teammate-review deadline and participant review rights. <br />
|- <br />
| activity_permissible? <br />
| Unified checker for any action, mapped through a dynamically computed <code>*_allowed_id</code>. <br />
|- <br />
| permission_status_for(action) <br />
| Returns <code>OK</code>, <code>Late</code>, or <code>No</code> for display and UI logic. <br />
|} <br />
<br />
These methods handle all the interactions between role state, deadline state, and the user’s participant record.<br />
<br />
<br />
==== Integration with the DueDate Model ====<br />
<br />
The <code>DueDate</code> model includes the <code>DueDatePermissions</code> module so that each deadline object inherently knows:<br />
<br />
* whether an action is allowed at that time<br />
* whether lateness is permitted<br />
* what the current permission status is<br />
* how to evaluate participant-specific permissions<br />
<br />
=== DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> mixin provides a unified interface for models that own due dates, such as <code>Assignment</code> and <code>SignUpTopic</code>.<br />
This module centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
This solves the previous issue where each model re-implemented its own partial or duplicated deadline logic.<br />
<br />
==== Purpose ====<br />
<br />
The mixin provides:<br />
<br />
* A generic mechanism to determine whether an action is currently permissible<br />
* Convenience methods for commonly used actions (submission, review, quiz, etc.)<br />
* Unified logic for resolving topic-specific vs assignment-level deadlines<br />
* A consistent method for retrieving the “next” deadline<br />
* Utility methods for copying due dates between models<br />
<br />
This leads to cleaner parent models and avoids repeated logic scattered across the codebase.<br />
<br />
==== Proposed Changes ====<br />
<br />
{| class="wikitable"<br />
|+ Summary of Methods in <code>DueDateActions</code><br />
|-<br />
! Method<br />
! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code><br />
| Generic checker that evaluates whether a given activity is permitted at the current time, based on the resolved due date.<br />
|-<br />
| <code>submission_permissible?</code><br />
| rowspan="6" | Convenience wrappers around <code>activity_permissible?</code> that provide activity-specific entry points while delegating the actual permission logic to the generic method. <br />
Mainly used to keep calling code and views readable, while ensuring all checks still go through the same underlying mechanism.<br />
|-<br />
| <code>review_permissible?</code><br />
|-<br />
| <code>teammate_review_permissible?</code><br />
|-<br />
| <code>quiz_permissible?</code><br />
|-<br />
| <code>team_formation_permissible?</code><br />
|-<br />
| <code>drop_topic_permissible?</code><br />
|-<br />
| <code>next_due_date(topic_id)</code><br />
| Resolves the next applicable deadline, preferring topic-specific deadlines when they exist and falling back to assignment-level deadlines otherwise.<br />
|-<br />
| <code>current_stage</code><br />
| Returns a human-readable stage name (e.g., “review”, “submission”, or “finished”) based on the next due date. Useful for UI display.<br />
|-<br />
| <code>has_topic_specific_deadlines?</code><br />
| Determines whether the assignment uses staggered or topic-specific deadlines.<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code><br />
| Utility for cloning an entire set of due dates to another parent object (e.g., duplicating an assignment).<br />
|}<br />
<br />
<br />
==== How Deadline Resolution Works ====<br />
<br />
When checking permissions or determining the current stage, the mixin:<br />
<br />
# Checks for topic-specific deadlines if a topic ID is provided<br />
# Selects the earliest upcoming deadline (topic-level or assignment-level)<br />
# Delegates permission checking to that deadline’s logic<br />
<br />
This creates a consistent and predictable flow:<br />
<br />
{| class="wikitable"<br />
|+ Deadline Resolution Pipeline <br />
|-<br />
! Step <br />
! Description <br />
|- <br />
| 1. Topic-specific? <br />
| If the assignment uses staggered/topic deadlines, topic-level entries are checked first. <br />
|- <br />
| 2. Assignment-level fallback <br />
| If no applicable topic deadline exists, the nearest assignment-level deadline is used. <br />
|- <br />
| 3. Permission evaluation <br />
| <code>DueDatePermissions</code> decides whether the action is allowed (OK / Late / No). <br />
|}<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts for different scenarios:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167207
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T05:23:45Z
<p>Skim253: /* Instructor's View */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Instructor's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|800px]]<br />
<br />
* In the Assignments tab, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
[[File:Due-date-topic-instructor.png|800px]]<br />
<br />
[[File:Due-date-topic-instructor-2.png|800px]]<br />
<br />
* In the Topics subtab, the ''DueDate'' of each topics are displayed.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules.<br />
Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility.<br />
This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
This diagram visualizes the redesigned architecture: blue/red/green indicate Rails models, orange indicates modules. <br />
Parent models call DueDateActions, which manages DueDate, while DueDatePermissions checks user rights using reference models. <br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<br />
The <code>deadline_types</code> table defines all canonical deadline categories used by the system.<br />
Each row represents one distinct deadline type, and every <code>DueDate</code> record must reference one of these entries through <code>deadline_type_id</code>.<br />
<br />
Below is a structural description of the table:<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure <br />
|- <br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each deadline type; referenced by <code>due_dates.deadline_type_id</code>. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic name (e.g., <code>submission</code>, <code>review</code>); must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of the deadline category. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Time when the row was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Time when the row was last updated. <br />
|} <br />
<br />
This schema ensures that:<br />
<br />
* Each deadline type has a unique name and description.<br />
* No duplicate entries can exist (e.g., the prior duplicated <code>team_formation</code> was cleaned).<br />
* All <code>DueDate</code> rows reference this master table through <code>deadline_type_id</code>.<br />
* The <code>id</code> column acts as the authoritative key used throughout permissions and due-date logic.<br />
<br />
Migrated constraints also ensure that <code>due_dates.deadline_type_id</code> is consistently stored as <code>BIGINT</code>, allowing a long-term stable keyspace.<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
Because each row in <code>deadline_types</code> is referenced by <code>DueDate.deadline_type_id</code>, the following definitions map directly to the schema above.<br />
<br />
Each ID corresponds exactly to the <code>id</code> field in the table and serves as the system-wide canonical reference for that deadline category.<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries <br />
|-<br />
! ID <br />
! Name <br />
! Description <br />
|- <br />
| 1 <br />
| submission <br />
| Student submission deadlines <br />
|- <br />
| 2 <br />
| review <br />
| Peer review deadlines <br />
|- <br />
| 3 <br />
| teammate_review <br />
| Team member evaluation deadlines <br />
|- <br />
| 5 <br />
| metareview <br />
| Meta-review deadlines (kept for backward compatibility) <br />
|- <br />
| 6 <br />
| drop_topic <br />
| Topic drop deadlines <br />
|- <br />
| 7 <br />
| signup <br />
| Topic signup deadlines <br />
|- <br />
| 8 <br />
| team_formation <br />
| Team formation deadlines (duplicate entries cleaned; ID 8 is canonical) <br />
|- <br />
| 11 <br />
| quiz <br />
| Quiz completion deadlines <br />
|} <br />
<br />
These definitions are seeded during migration and act as the source of truth for all deadline-related logic within <code>DueDate</code>, <code>DueDatePermissions</code>, and <code>DueDateActions</code>.<br />
By linking each <code>DueDate</code> to one of these entries through <code>deadline_type_id</code>, the system standardizes behavior and eliminates inconsistent ID or string comparisons from earlier implementations.<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <br />
* <code>OK</code> : Action is allowed without penalty<br />
* <code>Late</code> : Action is allowed but marked as late<br />
* <code>No</code> : Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, <code>quiz_allowed_id</code>, and others.<br />
This allows the system to determine user permissions by combining:<br />
<br />
# The current deadline’s allowed state<br />
# The participant’s role-based ability (submit, review, take quiz)<br />
<br />
This combination logic is implemented in <code>DueDatePermissions</code>.<br />
<br />
==== Database Schema ====<br />
The <code>deadline_rights</code> table stores the canonical permission states used across the entire due-date system.<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure <br />
|-<br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each permission state. Referenced by <code>due_dates.*_allowed_id</code> fields. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic permission name (<code>No</code>, <code>Late</code>, <code>OK</code>). Must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of what the permission state means. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was last updated. <br />
|} <br />
<br />
==== DeadlineRight Model ====<br />
Instead of embedding permission logic inside <code>DueDate</code>, the <code>DeadlineRight</code> model defines the meaning of each permission state.<br />
This removes magic strings (<code>"OK"</code>) and numeric comparisons and replaces them with expressive model-level semantics.<br />
<br />
{| class="wikitable"<br />
|+ Semantic Meaning Provided by <code>DeadlineRight</code> <br />
|-<br />
! Concept <br />
! Meaning <br />
|- <br />
| allows_action? <br />
| True for <code>OK</code> or <code>Late</code>; false for <code>No</code>. <br />
|- <br />
| denies_action? <br />
| True only for <code>No</code>. <br />
|- <br />
| allows_with_penalty? <br />
| True only for <code>Late</code>. <br />
|- <br />
| allows_without_penalty? <br />
| True only for <code>OK</code>. <br />
|- <br />
| permission_level <br />
| Numeric ordering: No = 0, Late = 1, OK = 2. Used for comparison and sorting. <br />
|} <br />
<br />
These behaviors allow other parts of the system—particularly <code>DueDatePermissions</code>—to make consistent, readable decisions.<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is simpler, more modular, and focused on representing a single deadline entry.<br />
Behavior previously embedded inside <code>DueDate</code> has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring <br />
|-<br />
! Concern <br />
! Where It Lives Now <br />
|- <br />
| Permission checking <br />
| <code>DueDatePermissions</code> module <br />
|- <br />
| Deadline-related actions (next deadline, stage name, deadline copying) <br />
| <code>DueDateActions</code> module (included in parent models) <br />
|- <br />
| Deadline type semantics <br />
| <code>DeadlineType</code> model <br />
|- <br />
| Core deadline data (due_at, round, parent) <br />
| <code>DueDate</code> model <br />
|} <br />
<br />
===== Instance-Based Behavior Instead of Class Methods =====<br />
<br />
Previously, many behaviors were class methods (e.g., copying deadlines).<br />
These methods did not reflect object-level behavior and often duplicated logic.<br />
<br />
The redesign moves these operations to:<br />
<br />
* instance methods for actions on a specific <code>DueDate</code><br />
* modules (DueDateActions) for higher-level behaviors on assignments or topics<br />
<br />
This separation:<br />
<br />
* improves testability<br />
* aligns with Rails conventions<br />
* avoids state duplication<br />
<br />
===== Clearer Query Methods =====<br />
<br />
The model now exposes simple, intuitive instance-level questions:<br />
<br />
{| class="wikitable"<br />
|+ Examples of Simplified State Queries <br />
|-<br />
! Method <br />
! Meaning <br />
|- <br />
| <code>upcoming?</code> <br />
| Whether the deadline occurs in the future <br />
|- <br />
| <code>overdue?</code> <br />
| Whether the deadline has already passed <br />
|- <br />
| <code>deadline_type_name</code> <br />
| Human-readable deadline type <br />
|} <br />
<br />
These small, composable predicates replace multiple ad-hoc comparisons scattered across the codebase.<br />
<br />
=== DueDatePermissions Mixin ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks.<br />
Instead of embedding checks directly into <code>Assignment</code> or <code>DueDate</code>, all permission logic now flows through <code>DueDatePermissions</code>.<br />
<br />
{| class="wikitable"<br />
|+ Meaning of Permission Methods <br />
! Method <br />
! What It Determines <br />
|- <br />
| can_submit? <br />
| Submission is allowed only if (1) the submission deadline is OK/Late and (2) the participant’s role permits submitting. <br />
|- <br />
| can_review? <br />
| Review is allowed only if the review deadline is OK/Late and the participant has review privileges. <br />
|- <br />
| can_take_quiz? <br />
| Quiz access is controlled by both quiz deadlines and participant quiz permissions. <br />
|- <br />
| can_review_teammate? <br />
| Teammate review uses both the teammate-review deadline and participant review rights. <br />
|- <br />
| activity_permissible? <br />
| Unified checker for any action, mapped through a dynamically computed <code>*_allowed_id</code>. <br />
|- <br />
| permission_status_for(action) <br />
| Returns <code>OK</code>, <code>Late</code>, or <code>No</code> for display and UI logic. <br />
|} <br />
<br />
These methods handle all the interactions between role state, deadline state, and the user’s participant record.<br />
<br />
<br />
==== Integration with the DueDate Model ====<br />
<br />
The <code>DueDate</code> model includes the <code>DueDatePermissions</code> module so that each deadline object inherently knows:<br />
<br />
* whether an action is allowed at that time<br />
* whether lateness is permitted<br />
* what the current permission status is<br />
* how to evaluate participant-specific permissions<br />
<br />
=== DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> mixin provides a unified interface for models that own due dates, such as <code>Assignment</code> and <code>SignUpTopic</code>.<br />
This module centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
This solves the previous issue where each model re-implemented its own partial or duplicated deadline logic.<br />
<br />
==== Purpose ====<br />
<br />
The mixin provides:<br />
<br />
* A generic mechanism to determine whether an action is currently permissible<br />
* Convenience methods for commonly used actions (submission, review, quiz, etc.)<br />
* Unified logic for resolving topic-specific vs assignment-level deadlines<br />
* A consistent method for retrieving the “next” deadline<br />
* Utility methods for copying due dates between models<br />
<br />
This leads to cleaner parent models and avoids repeated logic scattered across the codebase.<br />
<br />
==== Proposed Changes ====<br />
<br />
{| class="wikitable"<br />
|+ Summary of Methods in <code>DueDateActions</code><br />
|-<br />
! Method<br />
! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code><br />
| Generic checker that evaluates whether a given activity is permitted at the current time, based on the resolved due date.<br />
|-<br />
| <code>submission_permissible?</code><br />
| rowspan="6" | Convenience wrappers around <code>activity_permissible?</code> that provide activity-specific entry points while delegating the actual permission logic to the generic method. <br />
Mainly used to keep calling code and views readable, while ensuring all checks still go through the same underlying mechanism.<br />
|-<br />
| <code>review_permissible?</code><br />
|-<br />
| <code>teammate_review_permissible?</code><br />
|-<br />
| <code>quiz_permissible?</code><br />
|-<br />
| <code>team_formation_permissible?</code><br />
|-<br />
| <code>drop_topic_permissible?</code><br />
|-<br />
| <code>next_due_date(topic_id)</code><br />
| Resolves the next applicable deadline, preferring topic-specific deadlines when they exist and falling back to assignment-level deadlines otherwise.<br />
|-<br />
| <code>current_stage</code><br />
| Returns a human-readable stage name (e.g., “review”, “submission”, or “finished”) based on the next due date. Useful for UI display.<br />
|-<br />
| <code>has_topic_specific_deadlines?</code><br />
| Determines whether the assignment uses staggered or topic-specific deadlines.<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code><br />
| Utility for cloning an entire set of due dates to another parent object (e.g., duplicating an assignment).<br />
|}<br />
<br />
<br />
==== How Deadline Resolution Works ====<br />
<br />
When checking permissions or determining the current stage, the mixin:<br />
<br />
# Checks for topic-specific deadlines if a topic ID is provided<br />
# Selects the earliest upcoming deadline (topic-level or assignment-level)<br />
# Delegates permission checking to that deadline’s logic<br />
<br />
This creates a consistent and predictable flow:<br />
<br />
{| class="wikitable"<br />
|+ Deadline Resolution Pipeline <br />
|-<br />
! Step <br />
! Description <br />
|- <br />
| 1. Topic-specific? <br />
| If the assignment uses staggered/topic deadlines, topic-level entries are checked first. <br />
|- <br />
| 2. Assignment-level fallback <br />
| If no applicable topic deadline exists, the nearest assignment-level deadline is used. <br />
|- <br />
| 3. Permission evaluation <br />
| <code>DueDatePermissions</code> decides whether the action is allowed (OK / Late / No). <br />
|}<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts for different scenarios:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=File:Due-date-topic-instructor-2.png&diff=167206
File:Due-date-topic-instructor-2.png
2025-12-02T05:19:55Z
<p>Skim253: </p>
<hr />
<div></div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=File:Due-date-topic-instructor.png&diff=167205
File:Due-date-topic-instructor.png
2025-12-02T05:19:46Z
<p>Skim253: </p>
<hr />
<div></div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167204
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T05:07:42Z
<p>Skim253: /* Current Behavior */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Instructor's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules.<br />
Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility.<br />
This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
This diagram visualizes the redesigned architecture: blue/red/green indicate Rails models, orange indicates modules. <br />
Parent models call DueDateActions, which manages DueDate, while DueDatePermissions checks user rights using reference models. <br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<br />
The <code>deadline_types</code> table defines all canonical deadline categories used by the system.<br />
Each row represents one distinct deadline type, and every <code>DueDate</code> record must reference one of these entries through <code>deadline_type_id</code>.<br />
<br />
Below is a structural description of the table:<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure <br />
|- <br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each deadline type; referenced by <code>due_dates.deadline_type_id</code>. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic name (e.g., <code>submission</code>, <code>review</code>); must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of the deadline category. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Time when the row was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Time when the row was last updated. <br />
|} <br />
<br />
This schema ensures that:<br />
<br />
* Each deadline type has a unique name and description.<br />
* No duplicate entries can exist (e.g., the prior duplicated <code>team_formation</code> was cleaned).<br />
* All <code>DueDate</code> rows reference this master table through <code>deadline_type_id</code>.<br />
* The <code>id</code> column acts as the authoritative key used throughout permissions and due-date logic.<br />
<br />
Migrated constraints also ensure that <code>due_dates.deadline_type_id</code> is consistently stored as <code>BIGINT</code>, allowing a long-term stable keyspace.<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
Because each row in <code>deadline_types</code> is referenced by <code>DueDate.deadline_type_id</code>, the following definitions map directly to the schema above.<br />
<br />
Each ID corresponds exactly to the <code>id</code> field in the table and serves as the system-wide canonical reference for that deadline category.<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries <br />
|-<br />
! ID <br />
! Name <br />
! Description <br />
|- <br />
| 1 <br />
| submission <br />
| Student submission deadlines <br />
|- <br />
| 2 <br />
| review <br />
| Peer review deadlines <br />
|- <br />
| 3 <br />
| teammate_review <br />
| Team member evaluation deadlines <br />
|- <br />
| 5 <br />
| metareview <br />
| Meta-review deadlines (kept for backward compatibility) <br />
|- <br />
| 6 <br />
| drop_topic <br />
| Topic drop deadlines <br />
|- <br />
| 7 <br />
| signup <br />
| Topic signup deadlines <br />
|- <br />
| 8 <br />
| team_formation <br />
| Team formation deadlines (duplicate entries cleaned; ID 8 is canonical) <br />
|- <br />
| 11 <br />
| quiz <br />
| Quiz completion deadlines <br />
|} <br />
<br />
These definitions are seeded during migration and act as the source of truth for all deadline-related logic within <code>DueDate</code>, <code>DueDatePermissions</code>, and <code>DueDateActions</code>.<br />
By linking each <code>DueDate</code> to one of these entries through <code>deadline_type_id</code>, the system standardizes behavior and eliminates inconsistent ID or string comparisons from earlier implementations.<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <br />
* <code>OK</code> : Action is allowed without penalty<br />
* <code>Late</code> : Action is allowed but marked as late<br />
* <code>No</code> : Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, <code>quiz_allowed_id</code>, and others.<br />
This allows the system to determine user permissions by combining:<br />
<br />
# The current deadline’s allowed state<br />
# The participant’s role-based ability (submit, review, take quiz)<br />
<br />
This combination logic is implemented in <code>DueDatePermissions</code>.<br />
<br />
==== Database Schema ====<br />
The <code>deadline_rights</code> table stores the canonical permission states used across the entire due-date system.<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure <br />
|-<br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each permission state. Referenced by <code>due_dates.*_allowed_id</code> fields. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic permission name (<code>No</code>, <code>Late</code>, <code>OK</code>). Must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of what the permission state means. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was last updated. <br />
|} <br />
<br />
==== DeadlineRight Model ====<br />
Instead of embedding permission logic inside <code>DueDate</code>, the <code>DeadlineRight</code> model defines the meaning of each permission state.<br />
This removes magic strings (<code>"OK"</code>) and numeric comparisons and replaces them with expressive model-level semantics.<br />
<br />
{| class="wikitable"<br />
|+ Semantic Meaning Provided by <code>DeadlineRight</code> <br />
|-<br />
! Concept <br />
! Meaning <br />
|- <br />
| allows_action? <br />
| True for <code>OK</code> or <code>Late</code>; false for <code>No</code>. <br />
|- <br />
| denies_action? <br />
| True only for <code>No</code>. <br />
|- <br />
| allows_with_penalty? <br />
| True only for <code>Late</code>. <br />
|- <br />
| allows_without_penalty? <br />
| True only for <code>OK</code>. <br />
|- <br />
| permission_level <br />
| Numeric ordering: No = 0, Late = 1, OK = 2. Used for comparison and sorting. <br />
|} <br />
<br />
These behaviors allow other parts of the system—particularly <code>DueDatePermissions</code>—to make consistent, readable decisions.<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is simpler, more modular, and focused on representing a single deadline entry.<br />
Behavior previously embedded inside <code>DueDate</code> has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring <br />
|-<br />
! Concern <br />
! Where It Lives Now <br />
|- <br />
| Permission checking <br />
| <code>DueDatePermissions</code> module <br />
|- <br />
| Deadline-related actions (next deadline, stage name, deadline copying) <br />
| <code>DueDateActions</code> module (included in parent models) <br />
|- <br />
| Deadline type semantics <br />
| <code>DeadlineType</code> model <br />
|- <br />
| Core deadline data (due_at, round, parent) <br />
| <code>DueDate</code> model <br />
|} <br />
<br />
===== Instance-Based Behavior Instead of Class Methods =====<br />
<br />
Previously, many behaviors were class methods (e.g., copying deadlines).<br />
These methods did not reflect object-level behavior and often duplicated logic.<br />
<br />
The redesign moves these operations to:<br />
<br />
* instance methods for actions on a specific <code>DueDate</code><br />
* modules (DueDateActions) for higher-level behaviors on assignments or topics<br />
<br />
This separation:<br />
<br />
* improves testability<br />
* aligns with Rails conventions<br />
* avoids state duplication<br />
<br />
===== Clearer Query Methods =====<br />
<br />
The model now exposes simple, intuitive instance-level questions:<br />
<br />
{| class="wikitable"<br />
|+ Examples of Simplified State Queries <br />
|-<br />
! Method <br />
! Meaning <br />
|- <br />
| <code>upcoming?</code> <br />
| Whether the deadline occurs in the future <br />
|- <br />
| <code>overdue?</code> <br />
| Whether the deadline has already passed <br />
|- <br />
| <code>deadline_type_name</code> <br />
| Human-readable deadline type <br />
|} <br />
<br />
These small, composable predicates replace multiple ad-hoc comparisons scattered across the codebase.<br />
<br />
=== DueDatePermissions Mixin ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks.<br />
Instead of embedding checks directly into <code>Assignment</code> or <code>DueDate</code>, all permission logic now flows through <code>DueDatePermissions</code>.<br />
<br />
{| class="wikitable"<br />
|+ Meaning of Permission Methods <br />
! Method <br />
! What It Determines <br />
|- <br />
| can_submit? <br />
| Submission is allowed only if (1) the submission deadline is OK/Late and (2) the participant’s role permits submitting. <br />
|- <br />
| can_review? <br />
| Review is allowed only if the review deadline is OK/Late and the participant has review privileges. <br />
|- <br />
| can_take_quiz? <br />
| Quiz access is controlled by both quiz deadlines and participant quiz permissions. <br />
|- <br />
| can_review_teammate? <br />
| Teammate review uses both the teammate-review deadline and participant review rights. <br />
|- <br />
| activity_permissible? <br />
| Unified checker for any action, mapped through a dynamically computed <code>*_allowed_id</code>. <br />
|- <br />
| permission_status_for(action) <br />
| Returns <code>OK</code>, <code>Late</code>, or <code>No</code> for display and UI logic. <br />
|} <br />
<br />
These methods handle all the interactions between role state, deadline state, and the user’s participant record.<br />
<br />
<br />
==== Integration with the DueDate Model ====<br />
<br />
The <code>DueDate</code> model includes the <code>DueDatePermissions</code> module so that each deadline object inherently knows:<br />
<br />
* whether an action is allowed at that time<br />
* whether lateness is permitted<br />
* what the current permission status is<br />
* how to evaluate participant-specific permissions<br />
<br />
=== DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> mixin provides a unified interface for models that own due dates, such as <code>Assignment</code> and <code>SignUpTopic</code>.<br />
This module centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
This solves the previous issue where each model re-implemented its own partial or duplicated deadline logic.<br />
<br />
==== Purpose ====<br />
<br />
The mixin provides:<br />
<br />
* A generic mechanism to determine whether an action is currently permissible<br />
* Convenience methods for commonly used actions (submission, review, quiz, etc.)<br />
* Unified logic for resolving topic-specific vs assignment-level deadlines<br />
* A consistent method for retrieving the “next” deadline<br />
* Utility methods for copying due dates between models<br />
<br />
This leads to cleaner parent models and avoids repeated logic scattered across the codebase.<br />
<br />
==== Proposed Changes ====<br />
<br />
{| class="wikitable"<br />
|+ Summary of Methods in <code>DueDateActions</code><br />
|-<br />
! Method<br />
! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code><br />
| Generic checker that evaluates whether a given activity is permitted at the current time, based on the resolved due date.<br />
|-<br />
| <code>submission_permissible?</code><br />
| rowspan="6" | Convenience wrappers around <code>activity_permissible?</code> that provide activity-specific entry points while delegating the actual permission logic to the generic method. <br />
Mainly used to keep calling code and views readable, while ensuring all checks still go through the same underlying mechanism.<br />
|-<br />
| <code>review_permissible?</code><br />
|-<br />
| <code>teammate_review_permissible?</code><br />
|-<br />
| <code>quiz_permissible?</code><br />
|-<br />
| <code>team_formation_permissible?</code><br />
|-<br />
| <code>drop_topic_permissible?</code><br />
|-<br />
| <code>next_due_date(topic_id)</code><br />
| Resolves the next applicable deadline, preferring topic-specific deadlines when they exist and falling back to assignment-level deadlines otherwise.<br />
|-<br />
| <code>current_stage</code><br />
| Returns a human-readable stage name (e.g., “review”, “submission”, or “finished”) based on the next due date. Useful for UI display.<br />
|-<br />
| <code>has_topic_specific_deadlines?</code><br />
| Determines whether the assignment uses staggered or topic-specific deadlines.<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code><br />
| Utility for cloning an entire set of due dates to another parent object (e.g., duplicating an assignment).<br />
|}<br />
<br />
<br />
==== How Deadline Resolution Works ====<br />
<br />
When checking permissions or determining the current stage, the mixin:<br />
<br />
# Checks for topic-specific deadlines if a topic ID is provided<br />
# Selects the earliest upcoming deadline (topic-level or assignment-level)<br />
# Delegates permission checking to that deadline’s logic<br />
<br />
This creates a consistent and predictable flow:<br />
<br />
{| class="wikitable"<br />
|+ Deadline Resolution Pipeline <br />
|-<br />
! Step <br />
! Description <br />
|- <br />
| 1. Topic-specific? <br />
| If the assignment uses staggered/topic deadlines, topic-level entries are checked first. <br />
|- <br />
| 2. Assignment-level fallback <br />
| If no applicable topic deadline exists, the nearest assignment-level deadline is used. <br />
|- <br />
| 3. Permission evaluation <br />
| <code>DueDatePermissions</code> decides whether the action is allowed (OK / Late / No). <br />
|}<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts for different scenarios:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167203
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T05:07:02Z
<p>Skim253: /* DueDateActions Mixin */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules.<br />
Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility.<br />
This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
This diagram visualizes the redesigned architecture: blue/red/green indicate Rails models, orange indicates modules. <br />
Parent models call DueDateActions, which manages DueDate, while DueDatePermissions checks user rights using reference models. <br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<br />
The <code>deadline_types</code> table defines all canonical deadline categories used by the system.<br />
Each row represents one distinct deadline type, and every <code>DueDate</code> record must reference one of these entries through <code>deadline_type_id</code>.<br />
<br />
Below is a structural description of the table:<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure <br />
|- <br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each deadline type; referenced by <code>due_dates.deadline_type_id</code>. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic name (e.g., <code>submission</code>, <code>review</code>); must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of the deadline category. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Time when the row was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Time when the row was last updated. <br />
|} <br />
<br />
This schema ensures that:<br />
<br />
* Each deadline type has a unique name and description.<br />
* No duplicate entries can exist (e.g., the prior duplicated <code>team_formation</code> was cleaned).<br />
* All <code>DueDate</code> rows reference this master table through <code>deadline_type_id</code>.<br />
* The <code>id</code> column acts as the authoritative key used throughout permissions and due-date logic.<br />
<br />
Migrated constraints also ensure that <code>due_dates.deadline_type_id</code> is consistently stored as <code>BIGINT</code>, allowing a long-term stable keyspace.<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
Because each row in <code>deadline_types</code> is referenced by <code>DueDate.deadline_type_id</code>, the following definitions map directly to the schema above.<br />
<br />
Each ID corresponds exactly to the <code>id</code> field in the table and serves as the system-wide canonical reference for that deadline category.<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries <br />
|-<br />
! ID <br />
! Name <br />
! Description <br />
|- <br />
| 1 <br />
| submission <br />
| Student submission deadlines <br />
|- <br />
| 2 <br />
| review <br />
| Peer review deadlines <br />
|- <br />
| 3 <br />
| teammate_review <br />
| Team member evaluation deadlines <br />
|- <br />
| 5 <br />
| metareview <br />
| Meta-review deadlines (kept for backward compatibility) <br />
|- <br />
| 6 <br />
| drop_topic <br />
| Topic drop deadlines <br />
|- <br />
| 7 <br />
| signup <br />
| Topic signup deadlines <br />
|- <br />
| 8 <br />
| team_formation <br />
| Team formation deadlines (duplicate entries cleaned; ID 8 is canonical) <br />
|- <br />
| 11 <br />
| quiz <br />
| Quiz completion deadlines <br />
|} <br />
<br />
These definitions are seeded during migration and act as the source of truth for all deadline-related logic within <code>DueDate</code>, <code>DueDatePermissions</code>, and <code>DueDateActions</code>.<br />
By linking each <code>DueDate</code> to one of these entries through <code>deadline_type_id</code>, the system standardizes behavior and eliminates inconsistent ID or string comparisons from earlier implementations.<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <br />
* <code>OK</code> : Action is allowed without penalty<br />
* <code>Late</code> : Action is allowed but marked as late<br />
* <code>No</code> : Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, <code>quiz_allowed_id</code>, and others.<br />
This allows the system to determine user permissions by combining:<br />
<br />
# The current deadline’s allowed state<br />
# The participant’s role-based ability (submit, review, take quiz)<br />
<br />
This combination logic is implemented in <code>DueDatePermissions</code>.<br />
<br />
==== Database Schema ====<br />
The <code>deadline_rights</code> table stores the canonical permission states used across the entire due-date system.<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure <br />
|-<br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each permission state. Referenced by <code>due_dates.*_allowed_id</code> fields. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic permission name (<code>No</code>, <code>Late</code>, <code>OK</code>). Must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of what the permission state means. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was last updated. <br />
|} <br />
<br />
==== DeadlineRight Model ====<br />
Instead of embedding permission logic inside <code>DueDate</code>, the <code>DeadlineRight</code> model defines the meaning of each permission state.<br />
This removes magic strings (<code>"OK"</code>) and numeric comparisons and replaces them with expressive model-level semantics.<br />
<br />
{| class="wikitable"<br />
|+ Semantic Meaning Provided by <code>DeadlineRight</code> <br />
|-<br />
! Concept <br />
! Meaning <br />
|- <br />
| allows_action? <br />
| True for <code>OK</code> or <code>Late</code>; false for <code>No</code>. <br />
|- <br />
| denies_action? <br />
| True only for <code>No</code>. <br />
|- <br />
| allows_with_penalty? <br />
| True only for <code>Late</code>. <br />
|- <br />
| allows_without_penalty? <br />
| True only for <code>OK</code>. <br />
|- <br />
| permission_level <br />
| Numeric ordering: No = 0, Late = 1, OK = 2. Used for comparison and sorting. <br />
|} <br />
<br />
These behaviors allow other parts of the system—particularly <code>DueDatePermissions</code>—to make consistent, readable decisions.<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is simpler, more modular, and focused on representing a single deadline entry.<br />
Behavior previously embedded inside <code>DueDate</code> has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring <br />
|-<br />
! Concern <br />
! Where It Lives Now <br />
|- <br />
| Permission checking <br />
| <code>DueDatePermissions</code> module <br />
|- <br />
| Deadline-related actions (next deadline, stage name, deadline copying) <br />
| <code>DueDateActions</code> module (included in parent models) <br />
|- <br />
| Deadline type semantics <br />
| <code>DeadlineType</code> model <br />
|- <br />
| Core deadline data (due_at, round, parent) <br />
| <code>DueDate</code> model <br />
|} <br />
<br />
===== Instance-Based Behavior Instead of Class Methods =====<br />
<br />
Previously, many behaviors were class methods (e.g., copying deadlines).<br />
These methods did not reflect object-level behavior and often duplicated logic.<br />
<br />
The redesign moves these operations to:<br />
<br />
* instance methods for actions on a specific <code>DueDate</code><br />
* modules (DueDateActions) for higher-level behaviors on assignments or topics<br />
<br />
This separation:<br />
<br />
* improves testability<br />
* aligns with Rails conventions<br />
* avoids state duplication<br />
<br />
===== Clearer Query Methods =====<br />
<br />
The model now exposes simple, intuitive instance-level questions:<br />
<br />
{| class="wikitable"<br />
|+ Examples of Simplified State Queries <br />
|-<br />
! Method <br />
! Meaning <br />
|- <br />
| <code>upcoming?</code> <br />
| Whether the deadline occurs in the future <br />
|- <br />
| <code>overdue?</code> <br />
| Whether the deadline has already passed <br />
|- <br />
| <code>deadline_type_name</code> <br />
| Human-readable deadline type <br />
|} <br />
<br />
These small, composable predicates replace multiple ad-hoc comparisons scattered across the codebase.<br />
<br />
=== DueDatePermissions Mixin ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks.<br />
Instead of embedding checks directly into <code>Assignment</code> or <code>DueDate</code>, all permission logic now flows through <code>DueDatePermissions</code>.<br />
<br />
{| class="wikitable"<br />
|+ Meaning of Permission Methods <br />
! Method <br />
! What It Determines <br />
|- <br />
| can_submit? <br />
| Submission is allowed only if (1) the submission deadline is OK/Late and (2) the participant’s role permits submitting. <br />
|- <br />
| can_review? <br />
| Review is allowed only if the review deadline is OK/Late and the participant has review privileges. <br />
|- <br />
| can_take_quiz? <br />
| Quiz access is controlled by both quiz deadlines and participant quiz permissions. <br />
|- <br />
| can_review_teammate? <br />
| Teammate review uses both the teammate-review deadline and participant review rights. <br />
|- <br />
| activity_permissible? <br />
| Unified checker for any action, mapped through a dynamically computed <code>*_allowed_id</code>. <br />
|- <br />
| permission_status_for(action) <br />
| Returns <code>OK</code>, <code>Late</code>, or <code>No</code> for display and UI logic. <br />
|} <br />
<br />
These methods handle all the interactions between role state, deadline state, and the user’s participant record.<br />
<br />
<br />
==== Integration with the DueDate Model ====<br />
<br />
The <code>DueDate</code> model includes the <code>DueDatePermissions</code> module so that each deadline object inherently knows:<br />
<br />
* whether an action is allowed at that time<br />
* whether lateness is permitted<br />
* what the current permission status is<br />
* how to evaluate participant-specific permissions<br />
<br />
=== DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> mixin provides a unified interface for models that own due dates, such as <code>Assignment</code> and <code>SignUpTopic</code>.<br />
This module centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
This solves the previous issue where each model re-implemented its own partial or duplicated deadline logic.<br />
<br />
==== Purpose ====<br />
<br />
The mixin provides:<br />
<br />
* A generic mechanism to determine whether an action is currently permissible<br />
* Convenience methods for commonly used actions (submission, review, quiz, etc.)<br />
* Unified logic for resolving topic-specific vs assignment-level deadlines<br />
* A consistent method for retrieving the “next” deadline<br />
* Utility methods for copying due dates between models<br />
<br />
This leads to cleaner parent models and avoids repeated logic scattered across the codebase.<br />
<br />
==== Proposed Changes ====<br />
<br />
{| class="wikitable"<br />
|+ Summary of Methods in <code>DueDateActions</code><br />
|-<br />
! Method<br />
! Purpose<br />
|-<br />
| <code>activity_permissible?(activity)</code><br />
| Generic checker that evaluates whether a given activity is permitted at the current time, based on the resolved due date.<br />
|-<br />
| <code>submission_permissible?</code><br />
| rowspan="6" | Convenience wrappers around <code>activity_permissible?</code> that provide activity-specific entry points while delegating the actual permission logic to the generic method. <br />
Mainly used to keep calling code and views readable, while ensuring all checks still go through the same underlying mechanism.<br />
|-<br />
| <code>review_permissible?</code><br />
|-<br />
| <code>teammate_review_permissible?</code><br />
|-<br />
| <code>quiz_permissible?</code><br />
|-<br />
| <code>team_formation_permissible?</code><br />
|-<br />
| <code>drop_topic_permissible?</code><br />
|-<br />
| <code>next_due_date(topic_id)</code><br />
| Resolves the next applicable deadline, preferring topic-specific deadlines when they exist and falling back to assignment-level deadlines otherwise.<br />
|-<br />
| <code>current_stage</code><br />
| Returns a human-readable stage name (e.g., “review”, “submission”, or “finished”) based on the next due date. Useful for UI display.<br />
|-<br />
| <code>has_topic_specific_deadlines?</code><br />
| Determines whether the assignment uses staggered or topic-specific deadlines.<br />
|-<br />
| <code>copy_due_dates_to(new_parent)</code><br />
| Utility for cloning an entire set of due dates to another parent object (e.g., duplicating an assignment).<br />
|}<br />
<br />
<br />
==== How Deadline Resolution Works ====<br />
<br />
When checking permissions or determining the current stage, the mixin:<br />
<br />
# Checks for topic-specific deadlines if a topic ID is provided<br />
# Selects the earliest upcoming deadline (topic-level or assignment-level)<br />
# Delegates permission checking to that deadline’s logic<br />
<br />
This creates a consistent and predictable flow:<br />
<br />
{| class="wikitable"<br />
|+ Deadline Resolution Pipeline <br />
|-<br />
! Step <br />
! Description <br />
|- <br />
| 1. Topic-specific? <br />
| If the assignment uses staggered/topic deadlines, topic-level entries are checked first. <br />
|- <br />
| 2. Assignment-level fallback <br />
| If no applicable topic deadline exists, the nearest assignment-level deadline is used. <br />
|- <br />
| 3. Permission evaluation <br />
| <code>DueDatePermissions</code> decides whether the action is allowed (OK / Late / No). <br />
|}<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts for different scenarios:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167202
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T04:56:07Z
<p>Skim253: /* DueDateActions Mixin */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules.<br />
Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility.<br />
This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
This diagram visualizes the redesigned architecture: blue/red/green indicate Rails models, orange indicates modules. <br />
Parent models call DueDateActions, which manages DueDate, while DueDatePermissions checks user rights using reference models. <br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<br />
The <code>deadline_types</code> table defines all canonical deadline categories used by the system.<br />
Each row represents one distinct deadline type, and every <code>DueDate</code> record must reference one of these entries through <code>deadline_type_id</code>.<br />
<br />
Below is a structural description of the table:<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure <br />
|- <br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each deadline type; referenced by <code>due_dates.deadline_type_id</code>. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic name (e.g., <code>submission</code>, <code>review</code>); must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of the deadline category. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Time when the row was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Time when the row was last updated. <br />
|} <br />
<br />
This schema ensures that:<br />
<br />
* Each deadline type has a unique name and description.<br />
* No duplicate entries can exist (e.g., the prior duplicated <code>team_formation</code> was cleaned).<br />
* All <code>DueDate</code> rows reference this master table through <code>deadline_type_id</code>.<br />
* The <code>id</code> column acts as the authoritative key used throughout permissions and due-date logic.<br />
<br />
Migrated constraints also ensure that <code>due_dates.deadline_type_id</code> is consistently stored as <code>BIGINT</code>, allowing a long-term stable keyspace.<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
Because each row in <code>deadline_types</code> is referenced by <code>DueDate.deadline_type_id</code>, the following definitions map directly to the schema above.<br />
<br />
Each ID corresponds exactly to the <code>id</code> field in the table and serves as the system-wide canonical reference for that deadline category.<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries <br />
|-<br />
! ID <br />
! Name <br />
! Description <br />
|- <br />
| 1 <br />
| submission <br />
| Student submission deadlines <br />
|- <br />
| 2 <br />
| review <br />
| Peer review deadlines <br />
|- <br />
| 3 <br />
| teammate_review <br />
| Team member evaluation deadlines <br />
|- <br />
| 5 <br />
| metareview <br />
| Meta-review deadlines (kept for backward compatibility) <br />
|- <br />
| 6 <br />
| drop_topic <br />
| Topic drop deadlines <br />
|- <br />
| 7 <br />
| signup <br />
| Topic signup deadlines <br />
|- <br />
| 8 <br />
| team_formation <br />
| Team formation deadlines (duplicate entries cleaned; ID 8 is canonical) <br />
|- <br />
| 11 <br />
| quiz <br />
| Quiz completion deadlines <br />
|} <br />
<br />
These definitions are seeded during migration and act as the source of truth for all deadline-related logic within <code>DueDate</code>, <code>DueDatePermissions</code>, and <code>DueDateActions</code>.<br />
By linking each <code>DueDate</code> to one of these entries through <code>deadline_type_id</code>, the system standardizes behavior and eliminates inconsistent ID or string comparisons from earlier implementations.<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <br />
* <code>OK</code> : Action is allowed without penalty<br />
* <code>Late</code> : Action is allowed but marked as late<br />
* <code>No</code> : Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, <code>quiz_allowed_id</code>, and others.<br />
This allows the system to determine user permissions by combining:<br />
<br />
# The current deadline’s allowed state<br />
# The participant’s role-based ability (submit, review, take quiz)<br />
<br />
This combination logic is implemented in <code>DueDatePermissions</code>.<br />
<br />
==== Database Schema ====<br />
The <code>deadline_rights</code> table stores the canonical permission states used across the entire due-date system.<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure <br />
|-<br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each permission state. Referenced by <code>due_dates.*_allowed_id</code> fields. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic permission name (<code>No</code>, <code>Late</code>, <code>OK</code>). Must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of what the permission state means. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was last updated. <br />
|} <br />
<br />
==== DeadlineRight Model ====<br />
Instead of embedding permission logic inside <code>DueDate</code>, the <code>DeadlineRight</code> model defines the meaning of each permission state.<br />
This removes magic strings (<code>"OK"</code>) and numeric comparisons and replaces them with expressive model-level semantics.<br />
<br />
{| class="wikitable"<br />
|+ Semantic Meaning Provided by <code>DeadlineRight</code> <br />
|-<br />
! Concept <br />
! Meaning <br />
|- <br />
| allows_action? <br />
| True for <code>OK</code> or <code>Late</code>; false for <code>No</code>. <br />
|- <br />
| denies_action? <br />
| True only for <code>No</code>. <br />
|- <br />
| allows_with_penalty? <br />
| True only for <code>Late</code>. <br />
|- <br />
| allows_without_penalty? <br />
| True only for <code>OK</code>. <br />
|- <br />
| permission_level <br />
| Numeric ordering: No = 0, Late = 1, OK = 2. Used for comparison and sorting. <br />
|} <br />
<br />
These behaviors allow other parts of the system—particularly <code>DueDatePermissions</code>—to make consistent, readable decisions.<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is simpler, more modular, and focused on representing a single deadline entry.<br />
Behavior previously embedded inside <code>DueDate</code> has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring <br />
|-<br />
! Concern <br />
! Where It Lives Now <br />
|- <br />
| Permission checking <br />
| <code>DueDatePermissions</code> module <br />
|- <br />
| Deadline-related actions (next deadline, stage name, deadline copying) <br />
| <code>DueDateActions</code> module (included in parent models) <br />
|- <br />
| Deadline type semantics <br />
| <code>DeadlineType</code> model <br />
|- <br />
| Core deadline data (due_at, round, parent) <br />
| <code>DueDate</code> model <br />
|} <br />
<br />
===== Instance-Based Behavior Instead of Class Methods =====<br />
<br />
Previously, many behaviors were class methods (e.g., copying deadlines).<br />
These methods did not reflect object-level behavior and often duplicated logic.<br />
<br />
The redesign moves these operations to:<br />
<br />
* instance methods for actions on a specific <code>DueDate</code><br />
* modules (DueDateActions) for higher-level behaviors on assignments or topics<br />
<br />
This separation:<br />
<br />
* improves testability<br />
* aligns with Rails conventions<br />
* avoids state duplication<br />
<br />
===== Clearer Query Methods =====<br />
<br />
The model now exposes simple, intuitive instance-level questions:<br />
<br />
{| class="wikitable"<br />
|+ Examples of Simplified State Queries <br />
|-<br />
! Method <br />
! Meaning <br />
|- <br />
| <code>upcoming?</code> <br />
| Whether the deadline occurs in the future <br />
|- <br />
| <code>overdue?</code> <br />
| Whether the deadline has already passed <br />
|- <br />
| <code>deadline_type_name</code> <br />
| Human-readable deadline type <br />
|} <br />
<br />
These small, composable predicates replace multiple ad-hoc comparisons scattered across the codebase.<br />
<br />
=== DueDatePermissions Mixin ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks.<br />
Instead of embedding checks directly into <code>Assignment</code> or <code>DueDate</code>, all permission logic now flows through <code>DueDatePermissions</code>.<br />
<br />
{| class="wikitable"<br />
|+ Meaning of Permission Methods <br />
! Method <br />
! What It Determines <br />
|- <br />
| can_submit? <br />
| Submission is allowed only if (1) the submission deadline is OK/Late and (2) the participant’s role permits submitting. <br />
|- <br />
| can_review? <br />
| Review is allowed only if the review deadline is OK/Late and the participant has review privileges. <br />
|- <br />
| can_take_quiz? <br />
| Quiz access is controlled by both quiz deadlines and participant quiz permissions. <br />
|- <br />
| can_review_teammate? <br />
| Teammate review uses both the teammate-review deadline and participant review rights. <br />
|- <br />
| activity_permissible? <br />
| Unified checker for any action, mapped through a dynamically computed <code>*_allowed_id</code>. <br />
|- <br />
| permission_status_for(action) <br />
| Returns <code>OK</code>, <code>Late</code>, or <code>No</code> for display and UI logic. <br />
|} <br />
<br />
These methods handle all the interactions between role state, deadline state, and the user’s participant record.<br />
<br />
<br />
==== Integration with the DueDate Model ====<br />
<br />
The <code>DueDate</code> model includes the <code>DueDatePermissions</code> module so that each deadline object inherently knows:<br />
<br />
* whether an action is allowed at that time<br />
* whether lateness is permitted<br />
* what the current permission status is<br />
* how to evaluate participant-specific permissions<br />
<br />
=== DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> mixin provides a unified interface for models that own due dates, such as <code>Assignment</code> and <code>SignUpTopic</code>.<br />
This module centralizes the logic for querying upcoming deadlines and determining whether specific activities are currently allowed.<br />
<br />
This solves the previous issue where each model re-implemented its own partial or duplicated deadline logic.<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts for different scenarios:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167201
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T04:54:49Z
<p>Skim253: /* DueDatePermission Mixin */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules.<br />
Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility.<br />
This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
This diagram visualizes the redesigned architecture: blue/red/green indicate Rails models, orange indicates modules. <br />
Parent models call DueDateActions, which manages DueDate, while DueDatePermissions checks user rights using reference models. <br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<br />
The <code>deadline_types</code> table defines all canonical deadline categories used by the system.<br />
Each row represents one distinct deadline type, and every <code>DueDate</code> record must reference one of these entries through <code>deadline_type_id</code>.<br />
<br />
Below is a structural description of the table:<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure <br />
|- <br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each deadline type; referenced by <code>due_dates.deadline_type_id</code>. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic name (e.g., <code>submission</code>, <code>review</code>); must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of the deadline category. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Time when the row was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Time when the row was last updated. <br />
|} <br />
<br />
This schema ensures that:<br />
<br />
* Each deadline type has a unique name and description.<br />
* No duplicate entries can exist (e.g., the prior duplicated <code>team_formation</code> was cleaned).<br />
* All <code>DueDate</code> rows reference this master table through <code>deadline_type_id</code>.<br />
* The <code>id</code> column acts as the authoritative key used throughout permissions and due-date logic.<br />
<br />
Migrated constraints also ensure that <code>due_dates.deadline_type_id</code> is consistently stored as <code>BIGINT</code>, allowing a long-term stable keyspace.<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
Because each row in <code>deadline_types</code> is referenced by <code>DueDate.deadline_type_id</code>, the following definitions map directly to the schema above.<br />
<br />
Each ID corresponds exactly to the <code>id</code> field in the table and serves as the system-wide canonical reference for that deadline category.<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries <br />
|-<br />
! ID <br />
! Name <br />
! Description <br />
|- <br />
| 1 <br />
| submission <br />
| Student submission deadlines <br />
|- <br />
| 2 <br />
| review <br />
| Peer review deadlines <br />
|- <br />
| 3 <br />
| teammate_review <br />
| Team member evaluation deadlines <br />
|- <br />
| 5 <br />
| metareview <br />
| Meta-review deadlines (kept for backward compatibility) <br />
|- <br />
| 6 <br />
| drop_topic <br />
| Topic drop deadlines <br />
|- <br />
| 7 <br />
| signup <br />
| Topic signup deadlines <br />
|- <br />
| 8 <br />
| team_formation <br />
| Team formation deadlines (duplicate entries cleaned; ID 8 is canonical) <br />
|- <br />
| 11 <br />
| quiz <br />
| Quiz completion deadlines <br />
|} <br />
<br />
These definitions are seeded during migration and act as the source of truth for all deadline-related logic within <code>DueDate</code>, <code>DueDatePermissions</code>, and <code>DueDateActions</code>.<br />
By linking each <code>DueDate</code> to one of these entries through <code>deadline_type_id</code>, the system standardizes behavior and eliminates inconsistent ID or string comparisons from earlier implementations.<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <br />
* <code>OK</code> : Action is allowed without penalty<br />
* <code>Late</code> : Action is allowed but marked as late<br />
* <code>No</code> : Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, <code>quiz_allowed_id</code>, and others.<br />
This allows the system to determine user permissions by combining:<br />
<br />
# The current deadline’s allowed state<br />
# The participant’s role-based ability (submit, review, take quiz)<br />
<br />
This combination logic is implemented in <code>DueDatePermissions</code>.<br />
<br />
==== Database Schema ====<br />
The <code>deadline_rights</code> table stores the canonical permission states used across the entire due-date system.<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure <br />
|-<br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each permission state. Referenced by <code>due_dates.*_allowed_id</code> fields. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic permission name (<code>No</code>, <code>Late</code>, <code>OK</code>). Must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of what the permission state means. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was last updated. <br />
|} <br />
<br />
==== DeadlineRight Model ====<br />
Instead of embedding permission logic inside <code>DueDate</code>, the <code>DeadlineRight</code> model defines the meaning of each permission state.<br />
This removes magic strings (<code>"OK"</code>) and numeric comparisons and replaces them with expressive model-level semantics.<br />
<br />
{| class="wikitable"<br />
|+ Semantic Meaning Provided by <code>DeadlineRight</code> <br />
|-<br />
! Concept <br />
! Meaning <br />
|- <br />
| allows_action? <br />
| True for <code>OK</code> or <code>Late</code>; false for <code>No</code>. <br />
|- <br />
| denies_action? <br />
| True only for <code>No</code>. <br />
|- <br />
| allows_with_penalty? <br />
| True only for <code>Late</code>. <br />
|- <br />
| allows_without_penalty? <br />
| True only for <code>OK</code>. <br />
|- <br />
| permission_level <br />
| Numeric ordering: No = 0, Late = 1, OK = 2. Used for comparison and sorting. <br />
|} <br />
<br />
These behaviors allow other parts of the system—particularly <code>DueDatePermissions</code>—to make consistent, readable decisions.<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is simpler, more modular, and focused on representing a single deadline entry.<br />
Behavior previously embedded inside <code>DueDate</code> has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring <br />
|-<br />
! Concern <br />
! Where It Lives Now <br />
|- <br />
| Permission checking <br />
| <code>DueDatePermissions</code> module <br />
|- <br />
| Deadline-related actions (next deadline, stage name, deadline copying) <br />
| <code>DueDateActions</code> module (included in parent models) <br />
|- <br />
| Deadline type semantics <br />
| <code>DeadlineType</code> model <br />
|- <br />
| Core deadline data (due_at, round, parent) <br />
| <code>DueDate</code> model <br />
|} <br />
<br />
===== Instance-Based Behavior Instead of Class Methods =====<br />
<br />
Previously, many behaviors were class methods (e.g., copying deadlines).<br />
These methods did not reflect object-level behavior and often duplicated logic.<br />
<br />
The redesign moves these operations to:<br />
<br />
* instance methods for actions on a specific <code>DueDate</code><br />
* modules (DueDateActions) for higher-level behaviors on assignments or topics<br />
<br />
This separation:<br />
<br />
* improves testability<br />
* aligns with Rails conventions<br />
* avoids state duplication<br />
<br />
===== Clearer Query Methods =====<br />
<br />
The model now exposes simple, intuitive instance-level questions:<br />
<br />
{| class="wikitable"<br />
|+ Examples of Simplified State Queries <br />
|-<br />
! Method <br />
! Meaning <br />
|- <br />
| <code>upcoming?</code> <br />
| Whether the deadline occurs in the future <br />
|- <br />
| <code>overdue?</code> <br />
| Whether the deadline has already passed <br />
|- <br />
| <code>deadline_type_name</code> <br />
| Human-readable deadline type <br />
|} <br />
<br />
These small, composable predicates replace multiple ad-hoc comparisons scattered across the codebase.<br />
<br />
=== DueDatePermissions Mixin ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks.<br />
Instead of embedding checks directly into <code>Assignment</code> or <code>DueDate</code>, all permission logic now flows through <code>DueDatePermissions</code>.<br />
<br />
{| class="wikitable"<br />
|+ Meaning of Permission Methods <br />
! Method <br />
! What It Determines <br />
|- <br />
| can_submit? <br />
| Submission is allowed only if (1) the submission deadline is OK/Late and (2) the participant’s role permits submitting. <br />
|- <br />
| can_review? <br />
| Review is allowed only if the review deadline is OK/Late and the participant has review privileges. <br />
|- <br />
| can_take_quiz? <br />
| Quiz access is controlled by both quiz deadlines and participant quiz permissions. <br />
|- <br />
| can_review_teammate? <br />
| Teammate review uses both the teammate-review deadline and participant review rights. <br />
|- <br />
| activity_permissible? <br />
| Unified checker for any action, mapped through a dynamically computed <code>*_allowed_id</code>. <br />
|- <br />
| permission_status_for(action) <br />
| Returns <code>OK</code>, <code>Late</code>, or <code>No</code> for display and UI logic. <br />
|} <br />
<br />
These methods handle all the interactions between role state, deadline state, and the user’s participant record.<br />
<br />
<br />
==== Integration with the DueDate Model ====<br />
<br />
The <code>DueDate</code> model includes the <code>DueDatePermissions</code> module so that each deadline object inherently knows:<br />
<br />
* whether an action is allowed at that time<br />
* whether lateness is permitted<br />
* what the current permission status is<br />
* how to evaluate participant-specific permissions<br />
<br />
=== DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts for different scenarios:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167200
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T04:53:23Z
<p>Skim253: /* Permission-Checking Methods */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules.<br />
Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility.<br />
This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
This diagram visualizes the redesigned architecture: blue/red/green indicate Rails models, orange indicates modules. <br />
Parent models call DueDateActions, which manages DueDate, while DueDatePermissions checks user rights using reference models. <br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<br />
The <code>deadline_types</code> table defines all canonical deadline categories used by the system.<br />
Each row represents one distinct deadline type, and every <code>DueDate</code> record must reference one of these entries through <code>deadline_type_id</code>.<br />
<br />
Below is a structural description of the table:<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure <br />
|- <br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each deadline type; referenced by <code>due_dates.deadline_type_id</code>. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic name (e.g., <code>submission</code>, <code>review</code>); must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of the deadline category. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Time when the row was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Time when the row was last updated. <br />
|} <br />
<br />
This schema ensures that:<br />
<br />
* Each deadline type has a unique name and description.<br />
* No duplicate entries can exist (e.g., the prior duplicated <code>team_formation</code> was cleaned).<br />
* All <code>DueDate</code> rows reference this master table through <code>deadline_type_id</code>.<br />
* The <code>id</code> column acts as the authoritative key used throughout permissions and due-date logic.<br />
<br />
Migrated constraints also ensure that <code>due_dates.deadline_type_id</code> is consistently stored as <code>BIGINT</code>, allowing a long-term stable keyspace.<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
Because each row in <code>deadline_types</code> is referenced by <code>DueDate.deadline_type_id</code>, the following definitions map directly to the schema above.<br />
<br />
Each ID corresponds exactly to the <code>id</code> field in the table and serves as the system-wide canonical reference for that deadline category.<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries <br />
|-<br />
! ID <br />
! Name <br />
! Description <br />
|- <br />
| 1 <br />
| submission <br />
| Student submission deadlines <br />
|- <br />
| 2 <br />
| review <br />
| Peer review deadlines <br />
|- <br />
| 3 <br />
| teammate_review <br />
| Team member evaluation deadlines <br />
|- <br />
| 5 <br />
| metareview <br />
| Meta-review deadlines (kept for backward compatibility) <br />
|- <br />
| 6 <br />
| drop_topic <br />
| Topic drop deadlines <br />
|- <br />
| 7 <br />
| signup <br />
| Topic signup deadlines <br />
|- <br />
| 8 <br />
| team_formation <br />
| Team formation deadlines (duplicate entries cleaned; ID 8 is canonical) <br />
|- <br />
| 11 <br />
| quiz <br />
| Quiz completion deadlines <br />
|} <br />
<br />
These definitions are seeded during migration and act as the source of truth for all deadline-related logic within <code>DueDate</code>, <code>DueDatePermissions</code>, and <code>DueDateActions</code>.<br />
By linking each <code>DueDate</code> to one of these entries through <code>deadline_type_id</code>, the system standardizes behavior and eliminates inconsistent ID or string comparisons from earlier implementations.<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <br />
* <code>OK</code> : Action is allowed without penalty<br />
* <code>Late</code> : Action is allowed but marked as late<br />
* <code>No</code> : Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, <code>quiz_allowed_id</code>, and others.<br />
This allows the system to determine user permissions by combining:<br />
<br />
# The current deadline’s allowed state<br />
# The participant’s role-based ability (submit, review, take quiz)<br />
<br />
This combination logic is implemented in <code>DueDatePermissions</code>.<br />
<br />
==== Database Schema ====<br />
The <code>deadline_rights</code> table stores the canonical permission states used across the entire due-date system.<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure <br />
|-<br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each permission state. Referenced by <code>due_dates.*_allowed_id</code> fields. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic permission name (<code>No</code>, <code>Late</code>, <code>OK</code>). Must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of what the permission state means. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was last updated. <br />
|} <br />
<br />
==== DeadlineRight Model ====<br />
Instead of embedding permission logic inside <code>DueDate</code>, the <code>DeadlineRight</code> model defines the meaning of each permission state.<br />
This removes magic strings (<code>"OK"</code>) and numeric comparisons and replaces them with expressive model-level semantics.<br />
<br />
{| class="wikitable"<br />
|+ Semantic Meaning Provided by <code>DeadlineRight</code> <br />
|-<br />
! Concept <br />
! Meaning <br />
|- <br />
| allows_action? <br />
| True for <code>OK</code> or <code>Late</code>; false for <code>No</code>. <br />
|- <br />
| denies_action? <br />
| True only for <code>No</code>. <br />
|- <br />
| allows_with_penalty? <br />
| True only for <code>Late</code>. <br />
|- <br />
| allows_without_penalty? <br />
| True only for <code>OK</code>. <br />
|- <br />
| permission_level <br />
| Numeric ordering: No = 0, Late = 1, OK = 2. Used for comparison and sorting. <br />
|} <br />
<br />
These behaviors allow other parts of the system—particularly <code>DueDatePermissions</code>—to make consistent, readable decisions.<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is simpler, more modular, and focused on representing a single deadline entry.<br />
Behavior previously embedded inside <code>DueDate</code> has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring <br />
|-<br />
! Concern <br />
! Where It Lives Now <br />
|- <br />
| Permission checking <br />
| <code>DueDatePermissions</code> module <br />
|- <br />
| Deadline-related actions (next deadline, stage name, deadline copying) <br />
| <code>DueDateActions</code> module (included in parent models) <br />
|- <br />
| Deadline type semantics <br />
| <code>DeadlineType</code> model <br />
|- <br />
| Core deadline data (due_at, round, parent) <br />
| <code>DueDate</code> model <br />
|} <br />
<br />
===== Instance-Based Behavior Instead of Class Methods =====<br />
<br />
Previously, many behaviors were class methods (e.g., copying deadlines).<br />
These methods did not reflect object-level behavior and often duplicated logic.<br />
<br />
The redesign moves these operations to:<br />
<br />
* instance methods for actions on a specific <code>DueDate</code><br />
* modules (DueDateActions) for higher-level behaviors on assignments or topics<br />
<br />
This separation:<br />
<br />
* improves testability<br />
* aligns with Rails conventions<br />
* avoids state duplication<br />
<br />
===== Clearer Query Methods =====<br />
<br />
The model now exposes simple, intuitive instance-level questions:<br />
<br />
{| class="wikitable"<br />
|+ Examples of Simplified State Queries <br />
|-<br />
! Method <br />
! Meaning <br />
|- <br />
| <code>upcoming?</code> <br />
| Whether the deadline occurs in the future <br />
|- <br />
| <code>overdue?</code> <br />
| Whether the deadline has already passed <br />
|- <br />
| <code>deadline_type_name</code> <br />
| Human-readable deadline type <br />
|} <br />
<br />
These small, composable predicates replace multiple ad-hoc comparisons scattered across the codebase.<br />
<br />
=== DueDatePermission Mixin ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks.<br />
Instead of embedding checks directly into <code>Assignment</code> or <code>DueDate</code>, all permission logic now flows through <code>DueDatePermissions</code>.<br />
<br />
{| class="wikitable"<br />
|+ Meaning of Permission Methods <br />
! Method <br />
! What It Determines <br />
|- <br />
| can_submit? <br />
| Submission is allowed only if (1) the submission deadline is OK/Late and (2) the participant’s role permits submitting. <br />
|- <br />
| can_review? <br />
| Review is allowed only if the review deadline is OK/Late and the participant has review privileges. <br />
|- <br />
| can_take_quiz? <br />
| Quiz access is controlled by both quiz deadlines and participant quiz permissions. <br />
|- <br />
| can_review_teammate? <br />
| Teammate review uses both the teammate-review deadline and participant review rights. <br />
|- <br />
| activity_permissible? <br />
| Unified checker for any action, mapped through a dynamically computed <code>*_allowed_id</code>. <br />
|- <br />
| permission_status_for(action) <br />
| Returns <code>OK</code>, <code>Late</code>, or <code>No</code> for display and UI logic. <br />
|} <br />
<br />
These methods handle all the interactions between role state, deadline state, and the user’s participant record.<br />
<br />
<br />
==== Integration with the DueDate Model ====<br />
<br />
The <code>DueDate</code> model includes the <code>DueDatePermissions</code> module so that each deadline object inherently knows:<br />
<br />
* whether an action is allowed at that time<br />
* whether lateness is permitted<br />
* what the current permission status is<br />
* how to evaluate participant-specific permissions<br />
<br />
=== DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts for different scenarios:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167199
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T04:50:36Z
<p>Skim253: /* Permission-Checking Methods */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules.<br />
Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility.<br />
This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
This diagram visualizes the redesigned architecture: blue/red/green indicate Rails models, orange indicates modules. <br />
Parent models call DueDateActions, which manages DueDate, while DueDatePermissions checks user rights using reference models. <br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<br />
The <code>deadline_types</code> table defines all canonical deadline categories used by the system.<br />
Each row represents one distinct deadline type, and every <code>DueDate</code> record must reference one of these entries through <code>deadline_type_id</code>.<br />
<br />
Below is a structural description of the table:<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure <br />
|- <br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each deadline type; referenced by <code>due_dates.deadline_type_id</code>. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic name (e.g., <code>submission</code>, <code>review</code>); must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of the deadline category. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Time when the row was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Time when the row was last updated. <br />
|} <br />
<br />
This schema ensures that:<br />
<br />
* Each deadline type has a unique name and description.<br />
* No duplicate entries can exist (e.g., the prior duplicated <code>team_formation</code> was cleaned).<br />
* All <code>DueDate</code> rows reference this master table through <code>deadline_type_id</code>.<br />
* The <code>id</code> column acts as the authoritative key used throughout permissions and due-date logic.<br />
<br />
Migrated constraints also ensure that <code>due_dates.deadline_type_id</code> is consistently stored as <code>BIGINT</code>, allowing a long-term stable keyspace.<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
Because each row in <code>deadline_types</code> is referenced by <code>DueDate.deadline_type_id</code>, the following definitions map directly to the schema above.<br />
<br />
Each ID corresponds exactly to the <code>id</code> field in the table and serves as the system-wide canonical reference for that deadline category.<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries <br />
|-<br />
! ID <br />
! Name <br />
! Description <br />
|- <br />
| 1 <br />
| submission <br />
| Student submission deadlines <br />
|- <br />
| 2 <br />
| review <br />
| Peer review deadlines <br />
|- <br />
| 3 <br />
| teammate_review <br />
| Team member evaluation deadlines <br />
|- <br />
| 5 <br />
| metareview <br />
| Meta-review deadlines (kept for backward compatibility) <br />
|- <br />
| 6 <br />
| drop_topic <br />
| Topic drop deadlines <br />
|- <br />
| 7 <br />
| signup <br />
| Topic signup deadlines <br />
|- <br />
| 8 <br />
| team_formation <br />
| Team formation deadlines (duplicate entries cleaned; ID 8 is canonical) <br />
|- <br />
| 11 <br />
| quiz <br />
| Quiz completion deadlines <br />
|} <br />
<br />
These definitions are seeded during migration and act as the source of truth for all deadline-related logic within <code>DueDate</code>, <code>DueDatePermissions</code>, and <code>DueDateActions</code>.<br />
By linking each <code>DueDate</code> to one of these entries through <code>deadline_type_id</code>, the system standardizes behavior and eliminates inconsistent ID or string comparisons from earlier implementations.<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <br />
* <code>OK</code> : Action is allowed without penalty<br />
* <code>Late</code> : Action is allowed but marked as late<br />
* <code>No</code> : Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, <code>quiz_allowed_id</code>, and others.<br />
This allows the system to determine user permissions by combining:<br />
<br />
# The current deadline’s allowed state<br />
# The participant’s role-based ability (submit, review, take quiz)<br />
<br />
This combination logic is implemented in <code>DueDatePermissions</code>.<br />
<br />
==== Database Schema ====<br />
The <code>deadline_rights</code> table stores the canonical permission states used across the entire due-date system.<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure <br />
|-<br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each permission state. Referenced by <code>due_dates.*_allowed_id</code> fields. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic permission name (<code>No</code>, <code>Late</code>, <code>OK</code>). Must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of what the permission state means. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was last updated. <br />
|} <br />
<br />
==== DeadlineRight Model ====<br />
Instead of embedding permission logic inside <code>DueDate</code>, the <code>DeadlineRight</code> model defines the meaning of each permission state.<br />
This removes magic strings (<code>"OK"</code>) and numeric comparisons and replaces them with expressive model-level semantics.<br />
<br />
{| class="wikitable"<br />
|+ Semantic Meaning Provided by <code>DeadlineRight</code> <br />
|-<br />
! Concept <br />
! Meaning <br />
|- <br />
| allows_action? <br />
| True for <code>OK</code> or <code>Late</code>; false for <code>No</code>. <br />
|- <br />
| denies_action? <br />
| True only for <code>No</code>. <br />
|- <br />
| allows_with_penalty? <br />
| True only for <code>Late</code>. <br />
|- <br />
| allows_without_penalty? <br />
| True only for <code>OK</code>. <br />
|- <br />
| permission_level <br />
| Numeric ordering: No = 0, Late = 1, OK = 2. Used for comparison and sorting. <br />
|} <br />
<br />
These behaviors allow other parts of the system—particularly <code>DueDatePermissions</code>—to make consistent, readable decisions.<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is simpler, more modular, and focused on representing a single deadline entry.<br />
Behavior previously embedded inside <code>DueDate</code> has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring <br />
|-<br />
! Concern <br />
! Where It Lives Now <br />
|- <br />
| Permission checking <br />
| <code>DueDatePermissions</code> module <br />
|- <br />
| Deadline-related actions (next deadline, stage name, deadline copying) <br />
| <code>DueDateActions</code> module (included in parent models) <br />
|- <br />
| Deadline type semantics <br />
| <code>DeadlineType</code> model <br />
|- <br />
| Core deadline data (due_at, round, parent) <br />
| <code>DueDate</code> model <br />
|} <br />
<br />
===== Instance-Based Behavior Instead of Class Methods =====<br />
<br />
Previously, many behaviors were class methods (e.g., copying deadlines).<br />
These methods did not reflect object-level behavior and often duplicated logic.<br />
<br />
The redesign moves these operations to:<br />
<br />
* instance methods for actions on a specific <code>DueDate</code><br />
* modules (DueDateActions) for higher-level behaviors on assignments or topics<br />
<br />
This separation:<br />
<br />
* improves testability<br />
* aligns with Rails conventions<br />
* avoids state duplication<br />
<br />
===== Clearer Query Methods =====<br />
<br />
The model now exposes simple, intuitive instance-level questions:<br />
<br />
{| class="wikitable"<br />
|+ Examples of Simplified State Queries <br />
|-<br />
! Method <br />
! Meaning <br />
|- <br />
| <code>upcoming?</code> <br />
| Whether the deadline occurs in the future <br />
|- <br />
| <code>overdue?</code> <br />
| Whether the deadline has already passed <br />
|- <br />
| <code>deadline_type_name</code> <br />
| Human-readable deadline type <br />
|} <br />
<br />
These small, composable predicates replace multiple ad-hoc comparisons scattered across the codebase.<br />
<br />
=== Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks.<br />
Instead of embedding checks directly into <code>Assignment</code> or <code>DueDate</code>, all permission logic now flows through <code>DueDatePermissions</code>.<br />
<br />
{| class="wikitable"<br />
|+ Meaning of Permission Methods <br />
! Method <br />
! What It Determines <br />
|- <br />
| can_submit? <br />
| Submission is allowed only if (1) the submission deadline is OK/Late and (2) the participant’s role permits submitting. <br />
|- <br />
| can_review? <br />
| Review is allowed only if the review deadline is OK/Late and the participant has review privileges. <br />
|- <br />
| can_take_quiz? <br />
| Quiz access is controlled by both quiz deadlines and participant quiz permissions. <br />
|- <br />
| can_review_teammate? <br />
| Teammate review uses both the teammate-review deadline and participant review rights. <br />
|- <br />
| activity_permissible? <br />
| Unified checker for any action, mapped through a dynamically computed <code>*_allowed_id</code>. <br />
|- <br />
| permission_status_for(action) <br />
| Returns <code>OK</code>, <code>Late</code>, or <code>No</code> for display and UI logic. <br />
|} <br />
<br />
These methods handle all the interactions between role state, deadline state, and the user’s participant record.<br />
<br />
<br />
==== Integration with the DueDate Model ====<br />
<br />
The <code>DueDate</code> model includes the <code>DueDatePermissions</code> module so that each deadline object inherently knows:<br />
<br />
* whether an action is allowed at that time<br />
* whether lateness is permitted<br />
* what the current permission status is<br />
* how to evaluate participant-specific permissions<br />
<br />
=== DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts for different scenarios:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167198
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T04:40:45Z
<p>Skim253: /* Testing */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules.<br />
Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility.<br />
This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
This diagram visualizes the redesigned architecture: blue/red/green indicate Rails models, orange indicates modules. <br />
Parent models call DueDateActions, which manages DueDate, while DueDatePermissions checks user rights using reference models. <br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<br />
The <code>deadline_types</code> table defines all canonical deadline categories used by the system.<br />
Each row represents one distinct deadline type, and every <code>DueDate</code> record must reference one of these entries through <code>deadline_type_id</code>.<br />
<br />
Below is a structural description of the table:<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure <br />
|- <br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each deadline type; referenced by <code>due_dates.deadline_type_id</code>. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic name (e.g., <code>submission</code>, <code>review</code>); must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of the deadline category. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Time when the row was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Time when the row was last updated. <br />
|} <br />
<br />
This schema ensures that:<br />
<br />
* Each deadline type has a unique name and description.<br />
* No duplicate entries can exist (e.g., the prior duplicated <code>team_formation</code> was cleaned).<br />
* All <code>DueDate</code> rows reference this master table through <code>deadline_type_id</code>.<br />
* The <code>id</code> column acts as the authoritative key used throughout permissions and due-date logic.<br />
<br />
Migrated constraints also ensure that <code>due_dates.deadline_type_id</code> is consistently stored as <code>BIGINT</code>, allowing a long-term stable keyspace.<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
Because each row in <code>deadline_types</code> is referenced by <code>DueDate.deadline_type_id</code>, the following definitions map directly to the schema above.<br />
<br />
Each ID corresponds exactly to the <code>id</code> field in the table and serves as the system-wide canonical reference for that deadline category.<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries <br />
|-<br />
! ID <br />
! Name <br />
! Description <br />
|- <br />
| 1 <br />
| submission <br />
| Student submission deadlines <br />
|- <br />
| 2 <br />
| review <br />
| Peer review deadlines <br />
|- <br />
| 3 <br />
| teammate_review <br />
| Team member evaluation deadlines <br />
|- <br />
| 5 <br />
| metareview <br />
| Meta-review deadlines (kept for backward compatibility) <br />
|- <br />
| 6 <br />
| drop_topic <br />
| Topic drop deadlines <br />
|- <br />
| 7 <br />
| signup <br />
| Topic signup deadlines <br />
|- <br />
| 8 <br />
| team_formation <br />
| Team formation deadlines (duplicate entries cleaned; ID 8 is canonical) <br />
|- <br />
| 11 <br />
| quiz <br />
| Quiz completion deadlines <br />
|} <br />
<br />
These definitions are seeded during migration and act as the source of truth for all deadline-related logic within <code>DueDate</code>, <code>DueDatePermissions</code>, and <code>DueDateActions</code>.<br />
By linking each <code>DueDate</code> to one of these entries through <code>deadline_type_id</code>, the system standardizes behavior and eliminates inconsistent ID or string comparisons from earlier implementations.<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <br />
* <code>OK</code> : Action is allowed without penalty<br />
* <code>Late</code> : Action is allowed but marked as late<br />
* <code>No</code> : Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, <code>quiz_allowed_id</code>, and others.<br />
This allows the system to determine user permissions by combining:<br />
<br />
# The current deadline’s allowed state<br />
# The participant’s role-based ability (submit, review, take quiz)<br />
<br />
This combination logic is implemented in <code>DueDatePermissions</code>.<br />
<br />
==== Database Schema ====<br />
The <code>deadline_rights</code> table stores the canonical permission states used across the entire due-date system.<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure <br />
|-<br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each permission state. Referenced by <code>due_dates.*_allowed_id</code> fields. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic permission name (<code>No</code>, <code>Late</code>, <code>OK</code>). Must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of what the permission state means. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was last updated. <br />
|} <br />
<br />
==== DeadlineRight Model ====<br />
Instead of embedding permission logic inside <code>DueDate</code>, the <code>DeadlineRight</code> model defines the meaning of each permission state.<br />
This removes magic strings (<code>"OK"</code>) and numeric comparisons and replaces them with expressive model-level semantics.<br />
<br />
{| class="wikitable"<br />
|+ Semantic Meaning Provided by <code>DeadlineRight</code> <br />
|-<br />
! Concept <br />
! Meaning <br />
|- <br />
| allows_action? <br />
| True for <code>OK</code> or <code>Late</code>; false for <code>No</code>. <br />
|- <br />
| denies_action? <br />
| True only for <code>No</code>. <br />
|- <br />
| allows_with_penalty? <br />
| True only for <code>Late</code>. <br />
|- <br />
| allows_without_penalty? <br />
| True only for <code>OK</code>. <br />
|- <br />
| permission_level <br />
| Numeric ordering: No = 0, Late = 1, OK = 2. Used for comparison and sorting. <br />
|} <br />
<br />
These behaviors allow other parts of the system—particularly <code>DueDatePermissions</code>—to make consistent, readable decisions.<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is simpler, more modular, and focused on representing a single deadline entry.<br />
Behavior previously embedded inside <code>DueDate</code> has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring <br />
|-<br />
! Concern <br />
! Where It Lives Now <br />
|- <br />
| Permission checking <br />
| <code>DueDatePermissions</code> module <br />
|- <br />
| Deadline-related actions (next deadline, stage name, deadline copying) <br />
| <code>DueDateActions</code> module (included in parent models) <br />
|- <br />
| Deadline type semantics <br />
| <code>DeadlineType</code> model <br />
|- <br />
| Core deadline data (due_at, round, parent) <br />
| <code>DueDate</code> model <br />
|} <br />
<br />
===== Instance-Based Behavior Instead of Class Methods =====<br />
<br />
Previously, many behaviors were class methods (e.g., copying deadlines).<br />
These methods did not reflect object-level behavior and often duplicated logic.<br />
<br />
The redesign moves these operations to:<br />
<br />
* instance methods for actions on a specific <code>DueDate</code><br />
* modules (DueDateActions) for higher-level behaviors on assignments or topics<br />
<br />
This separation:<br />
<br />
* improves testability<br />
* aligns with Rails conventions<br />
* avoids state duplication<br />
<br />
===== Clearer Query Methods =====<br />
<br />
The model now exposes simple, intuitive instance-level questions:<br />
<br />
{| class="wikitable"<br />
|+ Examples of Simplified State Queries <br />
|-<br />
! Method <br />
! Meaning <br />
|- <br />
| <code>upcoming?</code> <br />
| Whether the deadline occurs in the future <br />
|- <br />
| <code>overdue?</code> <br />
| Whether the deadline has already passed <br />
|- <br />
| <code>deadline_type_name</code> <br />
| Human-readable deadline type <br />
|} <br />
<br />
These small, composable predicates replace multiple ad-hoc comparisons scattered across the codebase.<br />
<br />
=== Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts for different scenarios:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167197
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T04:40:03Z
<p>Skim253: /* Test Examples */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules.<br />
Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility.<br />
This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
This diagram visualizes the redesigned architecture: blue/red/green indicate Rails models, orange indicates modules. <br />
Parent models call DueDateActions, which manages DueDate, while DueDatePermissions checks user rights using reference models. <br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<br />
The <code>deadline_types</code> table defines all canonical deadline categories used by the system.<br />
Each row represents one distinct deadline type, and every <code>DueDate</code> record must reference one of these entries through <code>deadline_type_id</code>.<br />
<br />
Below is a structural description of the table:<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure <br />
|- <br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each deadline type; referenced by <code>due_dates.deadline_type_id</code>. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic name (e.g., <code>submission</code>, <code>review</code>); must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of the deadline category. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Time when the row was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Time when the row was last updated. <br />
|} <br />
<br />
This schema ensures that:<br />
<br />
* Each deadline type has a unique name and description.<br />
* No duplicate entries can exist (e.g., the prior duplicated <code>team_formation</code> was cleaned).<br />
* All <code>DueDate</code> rows reference this master table through <code>deadline_type_id</code>.<br />
* The <code>id</code> column acts as the authoritative key used throughout permissions and due-date logic.<br />
<br />
Migrated constraints also ensure that <code>due_dates.deadline_type_id</code> is consistently stored as <code>BIGINT</code>, allowing a long-term stable keyspace.<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
Because each row in <code>deadline_types</code> is referenced by <code>DueDate.deadline_type_id</code>, the following definitions map directly to the schema above.<br />
<br />
Each ID corresponds exactly to the <code>id</code> field in the table and serves as the system-wide canonical reference for that deadline category.<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries <br />
|-<br />
! ID <br />
! Name <br />
! Description <br />
|- <br />
| 1 <br />
| submission <br />
| Student submission deadlines <br />
|- <br />
| 2 <br />
| review <br />
| Peer review deadlines <br />
|- <br />
| 3 <br />
| teammate_review <br />
| Team member evaluation deadlines <br />
|- <br />
| 5 <br />
| metareview <br />
| Meta-review deadlines (kept for backward compatibility) <br />
|- <br />
| 6 <br />
| drop_topic <br />
| Topic drop deadlines <br />
|- <br />
| 7 <br />
| signup <br />
| Topic signup deadlines <br />
|- <br />
| 8 <br />
| team_formation <br />
| Team formation deadlines (duplicate entries cleaned; ID 8 is canonical) <br />
|- <br />
| 11 <br />
| quiz <br />
| Quiz completion deadlines <br />
|} <br />
<br />
These definitions are seeded during migration and act as the source of truth for all deadline-related logic within <code>DueDate</code>, <code>DueDatePermissions</code>, and <code>DueDateActions</code>.<br />
By linking each <code>DueDate</code> to one of these entries through <code>deadline_type_id</code>, the system standardizes behavior and eliminates inconsistent ID or string comparisons from earlier implementations.<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <br />
* <code>OK</code> : Action is allowed without penalty<br />
* <code>Late</code> : Action is allowed but marked as late<br />
* <code>No</code> : Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, <code>quiz_allowed_id</code>, and others.<br />
This allows the system to determine user permissions by combining:<br />
<br />
# The current deadline’s allowed state<br />
# The participant’s role-based ability (submit, review, take quiz)<br />
<br />
This combination logic is implemented in <code>DueDatePermissions</code>.<br />
<br />
==== Database Schema ====<br />
The <code>deadline_rights</code> table stores the canonical permission states used across the entire due-date system.<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure <br />
|-<br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each permission state. Referenced by <code>due_dates.*_allowed_id</code> fields. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic permission name (<code>No</code>, <code>Late</code>, <code>OK</code>). Must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of what the permission state means. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was last updated. <br />
|} <br />
<br />
==== DeadlineRight Model ====<br />
Instead of embedding permission logic inside <code>DueDate</code>, the <code>DeadlineRight</code> model defines the meaning of each permission state.<br />
This removes magic strings (<code>"OK"</code>) and numeric comparisons and replaces them with expressive model-level semantics.<br />
<br />
{| class="wikitable"<br />
|+ Semantic Meaning Provided by <code>DeadlineRight</code> <br />
|-<br />
! Concept <br />
! Meaning <br />
|- <br />
| allows_action? <br />
| True for <code>OK</code> or <code>Late</code>; false for <code>No</code>. <br />
|- <br />
| denies_action? <br />
| True only for <code>No</code>. <br />
|- <br />
| allows_with_penalty? <br />
| True only for <code>Late</code>. <br />
|- <br />
| allows_without_penalty? <br />
| True only for <code>OK</code>. <br />
|- <br />
| permission_level <br />
| Numeric ordering: No = 0, Late = 1, OK = 2. Used for comparison and sorting. <br />
|} <br />
<br />
These behaviors allow other parts of the system—particularly <code>DueDatePermissions</code>—to make consistent, readable decisions.<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is simpler, more modular, and focused on representing a single deadline entry.<br />
Behavior previously embedded inside <code>DueDate</code> has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring <br />
|-<br />
! Concern <br />
! Where It Lives Now <br />
|- <br />
| Permission checking <br />
| <code>DueDatePermissions</code> module <br />
|- <br />
| Deadline-related actions (next deadline, stage name, deadline copying) <br />
| <code>DueDateActions</code> module (included in parent models) <br />
|- <br />
| Deadline type semantics <br />
| <code>DeadlineType</code> model <br />
|- <br />
| Core deadline data (due_at, round, parent) <br />
| <code>DueDate</code> model <br />
|} <br />
<br />
===== Instance-Based Behavior Instead of Class Methods =====<br />
<br />
Previously, many behaviors were class methods (e.g., copying deadlines).<br />
These methods did not reflect object-level behavior and often duplicated logic.<br />
<br />
The redesign moves these operations to:<br />
<br />
* instance methods for actions on a specific <code>DueDate</code><br />
* modules (DueDateActions) for higher-level behaviors on assignments or topics<br />
<br />
This separation:<br />
<br />
* improves testability<br />
* aligns with Rails conventions<br />
* avoids state duplication<br />
<br />
===== Clearer Query Methods =====<br />
<br />
The model now exposes simple, intuitive instance-level questions:<br />
<br />
{| class="wikitable"<br />
|+ Examples of Simplified State Queries <br />
|-<br />
! Method <br />
! Meaning <br />
|- <br />
| <code>upcoming?</code> <br />
| Whether the deadline occurs in the future <br />
|- <br />
| <code>overdue?</code> <br />
| Whether the deadline has already passed <br />
|- <br />
| <code>deadline_type_name</code> <br />
| Human-readable deadline type <br />
|} <br />
<br />
These small, composable predicates replace multiple ad-hoc comparisons scattered across the codebase.<br />
<br />
=== Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Structure ===<br />
<br />
Tests follow RSpec best practices with nested contexts for different scenarios:<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''DueDate model''': 60+ examples covering all methods and edge cases<br />
* '''Context depth''': 2-3 levels for complex scenarios<br />
* '''Code coverage''': 100% coverage of DueDate model methods<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167196
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T04:36:46Z
<p>Skim253: /* DueDate Model Refactoring */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules.<br />
Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility.<br />
This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
This diagram visualizes the redesigned architecture: blue/red/green indicate Rails models, orange indicates modules. <br />
Parent models call DueDateActions, which manages DueDate, while DueDatePermissions checks user rights using reference models. <br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<br />
The <code>deadline_types</code> table defines all canonical deadline categories used by the system.<br />
Each row represents one distinct deadline type, and every <code>DueDate</code> record must reference one of these entries through <code>deadline_type_id</code>.<br />
<br />
Below is a structural description of the table:<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure <br />
|- <br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each deadline type; referenced by <code>due_dates.deadline_type_id</code>. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic name (e.g., <code>submission</code>, <code>review</code>); must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of the deadline category. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Time when the row was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Time when the row was last updated. <br />
|} <br />
<br />
This schema ensures that:<br />
<br />
* Each deadline type has a unique name and description.<br />
* No duplicate entries can exist (e.g., the prior duplicated <code>team_formation</code> was cleaned).<br />
* All <code>DueDate</code> rows reference this master table through <code>deadline_type_id</code>.<br />
* The <code>id</code> column acts as the authoritative key used throughout permissions and due-date logic.<br />
<br />
Migrated constraints also ensure that <code>due_dates.deadline_type_id</code> is consistently stored as <code>BIGINT</code>, allowing a long-term stable keyspace.<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
Because each row in <code>deadline_types</code> is referenced by <code>DueDate.deadline_type_id</code>, the following definitions map directly to the schema above.<br />
<br />
Each ID corresponds exactly to the <code>id</code> field in the table and serves as the system-wide canonical reference for that deadline category.<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries <br />
|-<br />
! ID <br />
! Name <br />
! Description <br />
|- <br />
| 1 <br />
| submission <br />
| Student submission deadlines <br />
|- <br />
| 2 <br />
| review <br />
| Peer review deadlines <br />
|- <br />
| 3 <br />
| teammate_review <br />
| Team member evaluation deadlines <br />
|- <br />
| 5 <br />
| metareview <br />
| Meta-review deadlines (kept for backward compatibility) <br />
|- <br />
| 6 <br />
| drop_topic <br />
| Topic drop deadlines <br />
|- <br />
| 7 <br />
| signup <br />
| Topic signup deadlines <br />
|- <br />
| 8 <br />
| team_formation <br />
| Team formation deadlines (duplicate entries cleaned; ID 8 is canonical) <br />
|- <br />
| 11 <br />
| quiz <br />
| Quiz completion deadlines <br />
|} <br />
<br />
These definitions are seeded during migration and act as the source of truth for all deadline-related logic within <code>DueDate</code>, <code>DueDatePermissions</code>, and <code>DueDateActions</code>.<br />
By linking each <code>DueDate</code> to one of these entries through <code>deadline_type_id</code>, the system standardizes behavior and eliminates inconsistent ID or string comparisons from earlier implementations.<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <br />
* <code>OK</code> : Action is allowed without penalty<br />
* <code>Late</code> : Action is allowed but marked as late<br />
* <code>No</code> : Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, <code>quiz_allowed_id</code>, and others.<br />
This allows the system to determine user permissions by combining:<br />
<br />
# The current deadline’s allowed state<br />
# The participant’s role-based ability (submit, review, take quiz)<br />
<br />
This combination logic is implemented in <code>DueDatePermissions</code>.<br />
<br />
==== Database Schema ====<br />
The <code>deadline_rights</code> table stores the canonical permission states used across the entire due-date system.<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure <br />
|-<br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each permission state. Referenced by <code>due_dates.*_allowed_id</code> fields. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic permission name (<code>No</code>, <code>Late</code>, <code>OK</code>). Must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of what the permission state means. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was last updated. <br />
|} <br />
<br />
==== DeadlineRight Model ====<br />
Instead of embedding permission logic inside <code>DueDate</code>, the <code>DeadlineRight</code> model defines the meaning of each permission state.<br />
This removes magic strings (<code>"OK"</code>) and numeric comparisons and replaces them with expressive model-level semantics.<br />
<br />
{| class="wikitable"<br />
|+ Semantic Meaning Provided by <code>DeadlineRight</code> <br />
|-<br />
! Concept <br />
! Meaning <br />
|- <br />
| allows_action? <br />
| True for <code>OK</code> or <code>Late</code>; false for <code>No</code>. <br />
|- <br />
| denies_action? <br />
| True only for <code>No</code>. <br />
|- <br />
| allows_with_penalty? <br />
| True only for <code>Late</code>. <br />
|- <br />
| allows_without_penalty? <br />
| True only for <code>OK</code>. <br />
|- <br />
| permission_level <br />
| Numeric ordering: No = 0, Late = 1, OK = 2. Used for comparison and sorting. <br />
|} <br />
<br />
These behaviors allow other parts of the system—particularly <code>DueDatePermissions</code>—to make consistent, readable decisions.<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
The redesigned <code>DueDate</code> model is simpler, more modular, and focused on representing a single deadline entry.<br />
Behavior previously embedded inside <code>DueDate</code> has been extracted into appropriate modules:<br />
<br />
{| class="wikitable"<br />
|+ Responsibility Distribution After Refactoring <br />
|-<br />
! Concern <br />
! Where It Lives Now <br />
|- <br />
| Permission checking <br />
| <code>DueDatePermissions</code> module <br />
|- <br />
| Deadline-related actions (next deadline, stage name, deadline copying) <br />
| <code>DueDateActions</code> module (included in parent models) <br />
|- <br />
| Deadline type semantics <br />
| <code>DeadlineType</code> model <br />
|- <br />
| Core deadline data (due_at, round, parent) <br />
| <code>DueDate</code> model <br />
|} <br />
<br />
===== Instance-Based Behavior Instead of Class Methods =====<br />
<br />
Previously, many behaviors were class methods (e.g., copying deadlines).<br />
These methods did not reflect object-level behavior and often duplicated logic.<br />
<br />
The redesign moves these operations to:<br />
<br />
* instance methods for actions on a specific <code>DueDate</code><br />
* modules (DueDateActions) for higher-level behaviors on assignments or topics<br />
<br />
This separation:<br />
<br />
* improves testability<br />
* aligns with Rails conventions<br />
* avoids state duplication<br />
<br />
===== Clearer Query Methods =====<br />
<br />
The model now exposes simple, intuitive instance-level questions:<br />
<br />
{| class="wikitable"<br />
|+ Examples of Simplified State Queries <br />
|-<br />
! Method <br />
! Meaning <br />
|- <br />
| <code>upcoming?</code> <br />
| Whether the deadline occurs in the future <br />
|- <br />
| <code>overdue?</code> <br />
| Whether the deadline has already passed <br />
|- <br />
| <code>deadline_type_name</code> <br />
| Human-readable deadline type <br />
|} <br />
<br />
These small, composable predicates replace multiple ad-hoc comparisons scattered across the codebase.<br />
<br />
=== Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Examples ===<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Validation with multiple assertions<br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: nil,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: 0<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on round field' do<br />
due_date.valid?<br />
expect(due_date.errors[:round]).to be_present<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
let(:due_date) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: nil<br />
)<br />
end<br />
<br />
it 'is valid' do<br />
expect(due_date).to be_valid<br />
end<br />
<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
<br />
# Scope with edge cases<br />
describe '.upcoming' do<br />
it 'returns only future due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to contain_exactly(upcoming_due_date1, upcoming_due_date2)<br />
end<br />
<br />
it 'orders results by due_at ascending' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to eq([upcoming_due_date1, upcoming_due_date2])<br />
end<br />
<br />
it 'excludes past due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).not_to include(past_due_date)<br />
end<br />
<br />
context 'when all due dates are in the past' do<br />
before do<br />
DueDate.destroy_all<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 3.days.ago,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'returns empty collection' do<br />
expect(DueDate.upcoming).to be_empty<br />
end<br />
end<br />
end<br />
<br />
# Instance method with error handling<br />
describe '#copy' do<br />
let(:original) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: late_right.id,<br />
round: 1<br />
)<br />
end<br />
<br />
let(:copied) { original.copy(assignment2.id) }<br />
<br />
it 'creates a new persisted record' do<br />
expect(copied).to be_persisted<br />
end<br />
<br />
it 'has different id from original' do<br />
expect(copied.id).not_to eq(original.id)<br />
end<br />
<br />
it 'preserves all attributes' do<br />
expect(copied.due_at).to eq(original.due_at)<br />
expect(copied.deadline_type_id).to eq(original.deadline_type_id)<br />
expect(copied.round).to eq(original.round)<br />
end<br />
<br />
context 'when copying to non-existent assignment' do<br />
it 'raises error' do<br />
expect do<br />
original.copy(99999)<br />
end.to raise_error(ActiveRecord::RecordNotFound)<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''DueDate model''': 60+ examples covering all methods and edge cases<br />
* '''Context depth''': 2-3 levels for complex scenarios<br />
* '''Code coverage''': 100% coverage of DueDate model methods<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167195
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T04:30:44Z
<p>Skim253: /* DeadlineRight Model Implementation */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules.<br />
Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility.<br />
This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
This diagram visualizes the redesigned architecture: blue/red/green indicate Rails models, orange indicates modules. <br />
Parent models call DueDateActions, which manages DueDate, while DueDatePermissions checks user rights using reference models. <br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<br />
The <code>deadline_types</code> table defines all canonical deadline categories used by the system.<br />
Each row represents one distinct deadline type, and every <code>DueDate</code> record must reference one of these entries through <code>deadline_type_id</code>.<br />
<br />
Below is a structural description of the table:<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure <br />
|- <br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each deadline type; referenced by <code>due_dates.deadline_type_id</code>. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic name (e.g., <code>submission</code>, <code>review</code>); must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of the deadline category. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Time when the row was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Time when the row was last updated. <br />
|} <br />
<br />
This schema ensures that:<br />
<br />
* Each deadline type has a unique name and description.<br />
* No duplicate entries can exist (e.g., the prior duplicated <code>team_formation</code> was cleaned).<br />
* All <code>DueDate</code> rows reference this master table through <code>deadline_type_id</code>.<br />
* The <code>id</code> column acts as the authoritative key used throughout permissions and due-date logic.<br />
<br />
Migrated constraints also ensure that <code>due_dates.deadline_type_id</code> is consistently stored as <code>BIGINT</code>, allowing a long-term stable keyspace.<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
Because each row in <code>deadline_types</code> is referenced by <code>DueDate.deadline_type_id</code>, the following definitions map directly to the schema above.<br />
<br />
Each ID corresponds exactly to the <code>id</code> field in the table and serves as the system-wide canonical reference for that deadline category.<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries <br />
|-<br />
! ID <br />
! Name <br />
! Description <br />
|- <br />
| 1 <br />
| submission <br />
| Student submission deadlines <br />
|- <br />
| 2 <br />
| review <br />
| Peer review deadlines <br />
|- <br />
| 3 <br />
| teammate_review <br />
| Team member evaluation deadlines <br />
|- <br />
| 5 <br />
| metareview <br />
| Meta-review deadlines (kept for backward compatibility) <br />
|- <br />
| 6 <br />
| drop_topic <br />
| Topic drop deadlines <br />
|- <br />
| 7 <br />
| signup <br />
| Topic signup deadlines <br />
|- <br />
| 8 <br />
| team_formation <br />
| Team formation deadlines (duplicate entries cleaned; ID 8 is canonical) <br />
|- <br />
| 11 <br />
| quiz <br />
| Quiz completion deadlines <br />
|} <br />
<br />
These definitions are seeded during migration and act as the source of truth for all deadline-related logic within <code>DueDate</code>, <code>DueDatePermissions</code>, and <code>DueDateActions</code>.<br />
By linking each <code>DueDate</code> to one of these entries through <code>deadline_type_id</code>, the system standardizes behavior and eliminates inconsistent ID or string comparisons from earlier implementations.<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <br />
* <code>OK</code> : Action is allowed without penalty<br />
* <code>Late</code> : Action is allowed but marked as late<br />
* <code>No</code> : Action is not permitted<br />
<br />
These values are referenced by <code>DueDate</code> through fields such as <code>submission_allowed_id</code>, <code>review_allowed_id</code>, <code>quiz_allowed_id</code>, and others.<br />
This allows the system to determine user permissions by combining:<br />
<br />
# The current deadline’s allowed state<br />
# The participant’s role-based ability (submit, review, take quiz)<br />
<br />
This combination logic is implemented in <code>DueDatePermissions</code>.<br />
<br />
==== Database Schema ====<br />
The <code>deadline_rights</code> table stores the canonical permission states used across the entire due-date system.<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_rights</code> Table Structure <br />
|-<br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each permission state. Referenced by <code>due_dates.*_allowed_id</code> fields. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic permission name (<code>No</code>, <code>Late</code>, <code>OK</code>). Must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of what the permission state means. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Timestamp when the entry was last updated. <br />
|} <br />
<br />
==== DeadlineRight Model ====<br />
Instead of embedding permission logic inside <code>DueDate</code>, the <code>DeadlineRight</code> model defines the meaning of each permission state.<br />
This removes magic strings (<code>"OK"</code>) and numeric comparisons and replaces them with expressive model-level semantics.<br />
<br />
{| class="wikitable"<br />
|+ Semantic Meaning Provided by <code>DeadlineRight</code> <br />
|-<br />
! Concept <br />
! Meaning <br />
|- <br />
| allows_action? <br />
| True for <code>OK</code> or <code>Late</code>; false for <code>No</code>. <br />
|- <br />
| denies_action? <br />
| True only for <code>No</code>. <br />
|- <br />
| allows_with_penalty? <br />
| True only for <code>Late</code>. <br />
|- <br />
| allows_without_penalty? <br />
| True only for <code>OK</code>. <br />
|- <br />
| permission_level <br />
| Numeric ordering: No = 0, Late = 1, OK = 2. Used for comparison and sorting. <br />
|} <br />
<br />
These behaviors allow other parts of the system—particularly <code>DueDatePermissions</code>—to make consistent, readable decisions.<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type, foreign_key: :deadline_type_id<br />
<br />
validates :due_at, presence: true<br />
validates :deadline_type_id, presence: true<br />
validates :parent, presence: true<br />
validates :round, numericality: { greater_than: 0 }, allow_nil: true<br />
<br />
# Scopes for common queries<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
scope :for_round, ->(round_num) { where(round: round_num) }<br />
scope :for_deadline_type, ->(type_name) { joins(:deadline_type).where(deadline_types: { name: type_name }) }<br />
<br />
# Instance methods replace class methods<br />
def copy(to_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
<br />
def set(deadline_type_id, parent_id, round)<br />
self.deadline_type_id = deadline_type_id<br />
self.parent_id = parent_id<br />
self.round = round<br />
save!<br />
end<br />
<br />
# Check if this deadline has passed<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
# Check if this deadline is upcoming<br />
def upcoming?<br />
due_at > Time.current<br />
end<br />
<br />
# Get the deadline type name<br />
def deadline_type_name<br />
deadline_type&.name<br />
end<br />
<br />
# Comparison method for sorting<br />
def <=>(other)<br />
return nil unless other.is_a?(DueDate)<br />
due_at <=> other.due_at<br />
end<br />
<br />
# Class methods for collection operations<br />
class << self<br />
def sort_due_dates(due_dates)<br />
due_dates.sort_by(&:due_at)<br />
end<br />
<br />
def any_future_due_dates?(due_dates)<br />
due_dates.any?(&:upcoming?)<br />
end<br />
<br />
def copy(from_assignment_id, to_assignment_id)<br />
from_assignment = Assignment.find(from_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
<br />
from_assignment.due_dates.each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
<br />
private<br />
<br />
before_save :set_default_round<br />
<br />
def set_default_round<br />
self.round ||= 1<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Examples ===<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Validation with multiple assertions<br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: nil,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: 0<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on round field' do<br />
due_date.valid?<br />
expect(due_date.errors[:round]).to be_present<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
let(:due_date) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: nil<br />
)<br />
end<br />
<br />
it 'is valid' do<br />
expect(due_date).to be_valid<br />
end<br />
<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
<br />
# Scope with edge cases<br />
describe '.upcoming' do<br />
it 'returns only future due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to contain_exactly(upcoming_due_date1, upcoming_due_date2)<br />
end<br />
<br />
it 'orders results by due_at ascending' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to eq([upcoming_due_date1, upcoming_due_date2])<br />
end<br />
<br />
it 'excludes past due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).not_to include(past_due_date)<br />
end<br />
<br />
context 'when all due dates are in the past' do<br />
before do<br />
DueDate.destroy_all<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 3.days.ago,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'returns empty collection' do<br />
expect(DueDate.upcoming).to be_empty<br />
end<br />
end<br />
end<br />
<br />
# Instance method with error handling<br />
describe '#copy' do<br />
let(:original) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: late_right.id,<br />
round: 1<br />
)<br />
end<br />
<br />
let(:copied) { original.copy(assignment2.id) }<br />
<br />
it 'creates a new persisted record' do<br />
expect(copied).to be_persisted<br />
end<br />
<br />
it 'has different id from original' do<br />
expect(copied.id).not_to eq(original.id)<br />
end<br />
<br />
it 'preserves all attributes' do<br />
expect(copied.due_at).to eq(original.due_at)<br />
expect(copied.deadline_type_id).to eq(original.deadline_type_id)<br />
expect(copied.round).to eq(original.round)<br />
end<br />
<br />
context 'when copying to non-existent assignment' do<br />
it 'raises error' do<br />
expect do<br />
original.copy(99999)<br />
end.to raise_error(ActiveRecord::RecordNotFound)<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''DueDate model''': 60+ examples covering all methods and edge cases<br />
* '''Context depth''': 2-3 levels for complex scenarios<br />
* '''Code coverage''': 100% coverage of DueDate model methods<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167194
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T04:22:50Z
<p>Skim253: /* DeadlineType Model Implementation */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules.<br />
Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility.<br />
This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
This diagram visualizes the redesigned architecture: blue/red/green indicate Rails models, orange indicates modules. <br />
Parent models call DueDateActions, which manages DueDate, while DueDatePermissions checks user rights using reference models. <br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<br />
The <code>deadline_types</code> table defines all canonical deadline categories used by the system.<br />
Each row represents one distinct deadline type, and every <code>DueDate</code> record must reference one of these entries through <code>deadline_type_id</code>.<br />
<br />
Below is a structural description of the table:<br />
<br />
{| class="wikitable"<br />
|+ <code>deadline_types</code> Table Structure <br />
|- <br />
! Column <br />
! Type <br />
! Description <br />
|- <br />
| id <br />
| BIGINT (Primary Key) <br />
| Unique identifier for each deadline type; referenced by <code>due_dates.deadline_type_id</code>. <br />
|- <br />
| name <br />
| VARCHAR(255) <br />
| Symbolic name (e.g., <code>submission</code>, <code>review</code>); must be unique. <br />
|- <br />
| description <br />
| TEXT <br />
| Human-readable explanation of the deadline category. <br />
|- <br />
| created_at <br />
| TIMESTAMP <br />
| Time when the row was created. <br />
|- <br />
| updated_at <br />
| TIMESTAMP <br />
| Time when the row was last updated. <br />
|} <br />
<br />
This schema ensures that:<br />
<br />
* Each deadline type has a unique name and description.<br />
* No duplicate entries can exist (e.g., the prior duplicated <code>team_formation</code> was cleaned).<br />
* All <code>DueDate</code> rows reference this master table through <code>deadline_type_id</code>.<br />
* The <code>id</code> column acts as the authoritative key used throughout permissions and due-date logic.<br />
<br />
Migrated constraints also ensure that <code>due_dates.deadline_type_id</code> is consistently stored as <code>BIGINT</code>, allowing a long-term stable keyspace.<br />
<br />
==== Deadline Type Definitions ====<br />
<br />
Because each row in <code>deadline_types</code> is referenced by <code>DueDate.deadline_type_id</code>, the following definitions map directly to the schema above.<br />
<br />
Each ID corresponds exactly to the <code>id</code> field in the table and serves as the system-wide canonical reference for that deadline category.<br />
<br />
{| class="wikitable"<br />
|+ Canonical Deadline Type Entries <br />
|-<br />
! ID <br />
! Name <br />
! Description <br />
|- <br />
| 1 <br />
| submission <br />
| Student submission deadlines <br />
|- <br />
| 2 <br />
| review <br />
| Peer review deadlines <br />
|- <br />
| 3 <br />
| teammate_review <br />
| Team member evaluation deadlines <br />
|- <br />
| 5 <br />
| metareview <br />
| Meta-review deadlines (kept for backward compatibility) <br />
|- <br />
| 6 <br />
| drop_topic <br />
| Topic drop deadlines <br />
|- <br />
| 7 <br />
| signup <br />
| Topic signup deadlines <br />
|- <br />
| 8 <br />
| team_formation <br />
| Team formation deadlines (duplicate entries cleaned; ID 8 is canonical) <br />
|- <br />
| 11 <br />
| quiz <br />
| Quiz completion deadlines <br />
|} <br />
<br />
These definitions are seeded during migration and act as the source of truth for all deadline-related logic within <code>DueDate</code>, <code>DueDatePermissions</code>, and <code>DueDateActions</code>.<br />
By linking each <code>DueDate</code> to one of these entries through <code>deadline_type_id</code>, the system standardizes behavior and eliminates inconsistent ID or string comparisons from earlier implementations.<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <code>OK</code> (action allowed), <code>Late</code> (action allowed with penalty), and <code>No</code> (action denied).<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_rights (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== DeadlineRight Model ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
# Permission checking methods<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
# Display methods<br />
def to_s<br />
name<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type, foreign_key: :deadline_type_id<br />
<br />
validates :due_at, presence: true<br />
validates :deadline_type_id, presence: true<br />
validates :parent, presence: true<br />
validates :round, numericality: { greater_than: 0 }, allow_nil: true<br />
<br />
# Scopes for common queries<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
scope :for_round, ->(round_num) { where(round: round_num) }<br />
scope :for_deadline_type, ->(type_name) { joins(:deadline_type).where(deadline_types: { name: type_name }) }<br />
<br />
# Instance methods replace class methods<br />
def copy(to_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
<br />
def set(deadline_type_id, parent_id, round)<br />
self.deadline_type_id = deadline_type_id<br />
self.parent_id = parent_id<br />
self.round = round<br />
save!<br />
end<br />
<br />
# Check if this deadline has passed<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
# Check if this deadline is upcoming<br />
def upcoming?<br />
due_at > Time.current<br />
end<br />
<br />
# Get the deadline type name<br />
def deadline_type_name<br />
deadline_type&.name<br />
end<br />
<br />
# Comparison method for sorting<br />
def <=>(other)<br />
return nil unless other.is_a?(DueDate)<br />
due_at <=> other.due_at<br />
end<br />
<br />
# Class methods for collection operations<br />
class << self<br />
def sort_due_dates(due_dates)<br />
due_dates.sort_by(&:due_at)<br />
end<br />
<br />
def any_future_due_dates?(due_dates)<br />
due_dates.any?(&:upcoming?)<br />
end<br />
<br />
def copy(from_assignment_id, to_assignment_id)<br />
from_assignment = Assignment.find(from_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
<br />
from_assignment.due_dates.each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
<br />
private<br />
<br />
before_save :set_default_round<br />
<br />
def set_default_round<br />
self.round ||= 1<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Examples ===<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Validation with multiple assertions<br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: nil,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: 0<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on round field' do<br />
due_date.valid?<br />
expect(due_date.errors[:round]).to be_present<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
let(:due_date) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: nil<br />
)<br />
end<br />
<br />
it 'is valid' do<br />
expect(due_date).to be_valid<br />
end<br />
<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
<br />
# Scope with edge cases<br />
describe '.upcoming' do<br />
it 'returns only future due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to contain_exactly(upcoming_due_date1, upcoming_due_date2)<br />
end<br />
<br />
it 'orders results by due_at ascending' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to eq([upcoming_due_date1, upcoming_due_date2])<br />
end<br />
<br />
it 'excludes past due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).not_to include(past_due_date)<br />
end<br />
<br />
context 'when all due dates are in the past' do<br />
before do<br />
DueDate.destroy_all<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 3.days.ago,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'returns empty collection' do<br />
expect(DueDate.upcoming).to be_empty<br />
end<br />
end<br />
end<br />
<br />
# Instance method with error handling<br />
describe '#copy' do<br />
let(:original) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: late_right.id,<br />
round: 1<br />
)<br />
end<br />
<br />
let(:copied) { original.copy(assignment2.id) }<br />
<br />
it 'creates a new persisted record' do<br />
expect(copied).to be_persisted<br />
end<br />
<br />
it 'has different id from original' do<br />
expect(copied.id).not_to eq(original.id)<br />
end<br />
<br />
it 'preserves all attributes' do<br />
expect(copied.due_at).to eq(original.due_at)<br />
expect(copied.deadline_type_id).to eq(original.deadline_type_id)<br />
expect(copied.round).to eq(original.round)<br />
end<br />
<br />
context 'when copying to non-existent assignment' do<br />
it 'raises error' do<br />
expect do<br />
original.copy(99999)<br />
end.to raise_error(ActiveRecord::RecordNotFound)<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''DueDate model''': 60+ examples covering all methods and edge cases<br />
* '''Context depth''': 2-3 levels for complex scenarios<br />
* '''Code coverage''': 100% coverage of DueDate model methods<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167193
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T04:05:08Z
<p>Skim253: /* Proposed Solution */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules.<br />
Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility.<br />
This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
This diagram visualizes the redesigned architecture: blue/red/green indicate Rails models, orange indicates modules. <br />
Parent models call DueDateActions, which manages DueDate, while DueDatePermissions checks user rights using reference models. <br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT NOT NULL,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <code>OK</code> (action allowed), <code>Late</code> (action allowed with penalty), and <code>No</code> (action denied).<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_rights (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== DeadlineRight Model ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
# Permission checking methods<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
# Display methods<br />
def to_s<br />
name<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type, foreign_key: :deadline_type_id<br />
<br />
validates :due_at, presence: true<br />
validates :deadline_type_id, presence: true<br />
validates :parent, presence: true<br />
validates :round, numericality: { greater_than: 0 }, allow_nil: true<br />
<br />
# Scopes for common queries<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
scope :for_round, ->(round_num) { where(round: round_num) }<br />
scope :for_deadline_type, ->(type_name) { joins(:deadline_type).where(deadline_types: { name: type_name }) }<br />
<br />
# Instance methods replace class methods<br />
def copy(to_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
<br />
def set(deadline_type_id, parent_id, round)<br />
self.deadline_type_id = deadline_type_id<br />
self.parent_id = parent_id<br />
self.round = round<br />
save!<br />
end<br />
<br />
# Check if this deadline has passed<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
# Check if this deadline is upcoming<br />
def upcoming?<br />
due_at > Time.current<br />
end<br />
<br />
# Get the deadline type name<br />
def deadline_type_name<br />
deadline_type&.name<br />
end<br />
<br />
# Comparison method for sorting<br />
def <=>(other)<br />
return nil unless other.is_a?(DueDate)<br />
due_at <=> other.due_at<br />
end<br />
<br />
# Class methods for collection operations<br />
class << self<br />
def sort_due_dates(due_dates)<br />
due_dates.sort_by(&:due_at)<br />
end<br />
<br />
def any_future_due_dates?(due_dates)<br />
due_dates.any?(&:upcoming?)<br />
end<br />
<br />
def copy(from_assignment_id, to_assignment_id)<br />
from_assignment = Assignment.find(from_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
<br />
from_assignment.due_dates.each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
<br />
private<br />
<br />
before_save :set_default_round<br />
<br />
def set_default_round<br />
self.round ||= 1<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Examples ===<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Validation with multiple assertions<br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: nil,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: 0<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on round field' do<br />
due_date.valid?<br />
expect(due_date.errors[:round]).to be_present<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
let(:due_date) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: nil<br />
)<br />
end<br />
<br />
it 'is valid' do<br />
expect(due_date).to be_valid<br />
end<br />
<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
<br />
# Scope with edge cases<br />
describe '.upcoming' do<br />
it 'returns only future due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to contain_exactly(upcoming_due_date1, upcoming_due_date2)<br />
end<br />
<br />
it 'orders results by due_at ascending' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to eq([upcoming_due_date1, upcoming_due_date2])<br />
end<br />
<br />
it 'excludes past due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).not_to include(past_due_date)<br />
end<br />
<br />
context 'when all due dates are in the past' do<br />
before do<br />
DueDate.destroy_all<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 3.days.ago,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'returns empty collection' do<br />
expect(DueDate.upcoming).to be_empty<br />
end<br />
end<br />
end<br />
<br />
# Instance method with error handling<br />
describe '#copy' do<br />
let(:original) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: late_right.id,<br />
round: 1<br />
)<br />
end<br />
<br />
let(:copied) { original.copy(assignment2.id) }<br />
<br />
it 'creates a new persisted record' do<br />
expect(copied).to be_persisted<br />
end<br />
<br />
it 'has different id from original' do<br />
expect(copied.id).not_to eq(original.id)<br />
end<br />
<br />
it 'preserves all attributes' do<br />
expect(copied.due_at).to eq(original.due_at)<br />
expect(copied.deadline_type_id).to eq(original.deadline_type_id)<br />
expect(copied.round).to eq(original.round)<br />
end<br />
<br />
context 'when copying to non-existent assignment' do<br />
it 'raises error' do<br />
expect do<br />
original.copy(99999)<br />
end.to raise_error(ActiveRecord::RecordNotFound)<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''DueDate model''': 60+ examples covering all methods and edge cases<br />
* '''Context depth''': 2-3 levels for complex scenarios<br />
* '''Code coverage''': 100% coverage of DueDate model methods<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167192
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T04:04:31Z
<p>Skim253: /* Proposed Solution */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules.<br />
Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility.<br />
This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
This diagram visualizes the redesigned architecture: blue/red/green indicate Rails models, orange indicates modules. <br />
Parent models call DueDateActions, which manages DueDate, while DueDatePermissions checks user rights using reference models. <br />
This separation clarifies responsibilities and improves modularity.<br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT NOT NULL,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <code>OK</code> (action allowed), <code>Late</code> (action allowed with penalty), and <code>No</code> (action denied).<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_rights (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== DeadlineRight Model ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
# Permission checking methods<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
# Display methods<br />
def to_s<br />
name<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type, foreign_key: :deadline_type_id<br />
<br />
validates :due_at, presence: true<br />
validates :deadline_type_id, presence: true<br />
validates :parent, presence: true<br />
validates :round, numericality: { greater_than: 0 }, allow_nil: true<br />
<br />
# Scopes for common queries<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
scope :for_round, ->(round_num) { where(round: round_num) }<br />
scope :for_deadline_type, ->(type_name) { joins(:deadline_type).where(deadline_types: { name: type_name }) }<br />
<br />
# Instance methods replace class methods<br />
def copy(to_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
<br />
def set(deadline_type_id, parent_id, round)<br />
self.deadline_type_id = deadline_type_id<br />
self.parent_id = parent_id<br />
self.round = round<br />
save!<br />
end<br />
<br />
# Check if this deadline has passed<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
# Check if this deadline is upcoming<br />
def upcoming?<br />
due_at > Time.current<br />
end<br />
<br />
# Get the deadline type name<br />
def deadline_type_name<br />
deadline_type&.name<br />
end<br />
<br />
# Comparison method for sorting<br />
def <=>(other)<br />
return nil unless other.is_a?(DueDate)<br />
due_at <=> other.due_at<br />
end<br />
<br />
# Class methods for collection operations<br />
class << self<br />
def sort_due_dates(due_dates)<br />
due_dates.sort_by(&:due_at)<br />
end<br />
<br />
def any_future_due_dates?(due_dates)<br />
due_dates.any?(&:upcoming?)<br />
end<br />
<br />
def copy(from_assignment_id, to_assignment_id)<br />
from_assignment = Assignment.find(from_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
<br />
from_assignment.due_dates.each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
<br />
private<br />
<br />
before_save :set_default_round<br />
<br />
def set_default_round<br />
self.round ||= 1<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Examples ===<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Validation with multiple assertions<br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: nil,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: 0<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on round field' do<br />
due_date.valid?<br />
expect(due_date.errors[:round]).to be_present<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
let(:due_date) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: nil<br />
)<br />
end<br />
<br />
it 'is valid' do<br />
expect(due_date).to be_valid<br />
end<br />
<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
<br />
# Scope with edge cases<br />
describe '.upcoming' do<br />
it 'returns only future due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to contain_exactly(upcoming_due_date1, upcoming_due_date2)<br />
end<br />
<br />
it 'orders results by due_at ascending' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to eq([upcoming_due_date1, upcoming_due_date2])<br />
end<br />
<br />
it 'excludes past due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).not_to include(past_due_date)<br />
end<br />
<br />
context 'when all due dates are in the past' do<br />
before do<br />
DueDate.destroy_all<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 3.days.ago,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'returns empty collection' do<br />
expect(DueDate.upcoming).to be_empty<br />
end<br />
end<br />
end<br />
<br />
# Instance method with error handling<br />
describe '#copy' do<br />
let(:original) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: late_right.id,<br />
round: 1<br />
)<br />
end<br />
<br />
let(:copied) { original.copy(assignment2.id) }<br />
<br />
it 'creates a new persisted record' do<br />
expect(copied).to be_persisted<br />
end<br />
<br />
it 'has different id from original' do<br />
expect(copied.id).not_to eq(original.id)<br />
end<br />
<br />
it 'preserves all attributes' do<br />
expect(copied.due_at).to eq(original.due_at)<br />
expect(copied.deadline_type_id).to eq(original.deadline_type_id)<br />
expect(copied.round).to eq(original.round)<br />
end<br />
<br />
context 'when copying to non-existent assignment' do<br />
it 'raises error' do<br />
expect do<br />
original.copy(99999)<br />
end.to raise_error(ActiveRecord::RecordNotFound)<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''DueDate model''': 60+ examples covering all methods and edge cases<br />
* '''Context depth''': 2-3 levels for complex scenarios<br />
* '''Code coverage''': 100% coverage of DueDate model methods<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167191
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T04:04:11Z
<p>Skim253: /* Proposed Solution */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
The proposed solution restructures the due date system by separating concerns across dedicated models and mixin modules.<br />
Deadline definitions (<code>DeadlineType</code>, <code>DeadlineRight</code>), core deadline data (<code>DueDate</code>), and behavioral logic (<code>DueDateActions</code>, <code>DueDatePermissions</code>) are isolated so each component has a single clear responsibility.<br />
This modular design improves readability, reduces coupling, and makes deadline-related behavior easier to extend and maintain.<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
This diagram visualizes the redesigned architecture: blue/red/green indicate Rails models, orange indicates modules. <br />
Parent models call DueDateActions, which manages DueDate, while DueDatePermissions checks user rights using reference models. <br />
This separation clarifies responsibilities and improves modularity.<br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT NOT NULL,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <code>OK</code> (action allowed), <code>Late</code> (action allowed with penalty), and <code>No</code> (action denied).<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_rights (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== DeadlineRight Model ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
# Permission checking methods<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
# Display methods<br />
def to_s<br />
name<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type, foreign_key: :deadline_type_id<br />
<br />
validates :due_at, presence: true<br />
validates :deadline_type_id, presence: true<br />
validates :parent, presence: true<br />
validates :round, numericality: { greater_than: 0 }, allow_nil: true<br />
<br />
# Scopes for common queries<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
scope :for_round, ->(round_num) { where(round: round_num) }<br />
scope :for_deadline_type, ->(type_name) { joins(:deadline_type).where(deadline_types: { name: type_name }) }<br />
<br />
# Instance methods replace class methods<br />
def copy(to_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
<br />
def set(deadline_type_id, parent_id, round)<br />
self.deadline_type_id = deadline_type_id<br />
self.parent_id = parent_id<br />
self.round = round<br />
save!<br />
end<br />
<br />
# Check if this deadline has passed<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
# Check if this deadline is upcoming<br />
def upcoming?<br />
due_at > Time.current<br />
end<br />
<br />
# Get the deadline type name<br />
def deadline_type_name<br />
deadline_type&.name<br />
end<br />
<br />
# Comparison method for sorting<br />
def <=>(other)<br />
return nil unless other.is_a?(DueDate)<br />
due_at <=> other.due_at<br />
end<br />
<br />
# Class methods for collection operations<br />
class << self<br />
def sort_due_dates(due_dates)<br />
due_dates.sort_by(&:due_at)<br />
end<br />
<br />
def any_future_due_dates?(due_dates)<br />
due_dates.any?(&:upcoming?)<br />
end<br />
<br />
def copy(from_assignment_id, to_assignment_id)<br />
from_assignment = Assignment.find(from_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
<br />
from_assignment.due_dates.each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
<br />
private<br />
<br />
before_save :set_default_round<br />
<br />
def set_default_round<br />
self.round ||= 1<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Examples ===<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Validation with multiple assertions<br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: nil,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: 0<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on round field' do<br />
due_date.valid?<br />
expect(due_date.errors[:round]).to be_present<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
let(:due_date) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: nil<br />
)<br />
end<br />
<br />
it 'is valid' do<br />
expect(due_date).to be_valid<br />
end<br />
<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
<br />
# Scope with edge cases<br />
describe '.upcoming' do<br />
it 'returns only future due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to contain_exactly(upcoming_due_date1, upcoming_due_date2)<br />
end<br />
<br />
it 'orders results by due_at ascending' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to eq([upcoming_due_date1, upcoming_due_date2])<br />
end<br />
<br />
it 'excludes past due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).not_to include(past_due_date)<br />
end<br />
<br />
context 'when all due dates are in the past' do<br />
before do<br />
DueDate.destroy_all<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 3.days.ago,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'returns empty collection' do<br />
expect(DueDate.upcoming).to be_empty<br />
end<br />
end<br />
end<br />
<br />
# Instance method with error handling<br />
describe '#copy' do<br />
let(:original) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: late_right.id,<br />
round: 1<br />
)<br />
end<br />
<br />
let(:copied) { original.copy(assignment2.id) }<br />
<br />
it 'creates a new persisted record' do<br />
expect(copied).to be_persisted<br />
end<br />
<br />
it 'has different id from original' do<br />
expect(copied.id).not_to eq(original.id)<br />
end<br />
<br />
it 'preserves all attributes' do<br />
expect(copied.due_at).to eq(original.due_at)<br />
expect(copied.deadline_type_id).to eq(original.deadline_type_id)<br />
expect(copied.round).to eq(original.round)<br />
end<br />
<br />
context 'when copying to non-existent assignment' do<br />
it 'raises error' do<br />
expect do<br />
original.copy(99999)<br />
end.to raise_error(ActiveRecord::RecordNotFound)<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''DueDate model''': 60+ examples covering all methods and edge cases<br />
* '''Context depth''': 2-3 levels for complex scenarios<br />
* '''Code coverage''': 100% coverage of DueDate model methods<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167190
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T03:53:53Z
<p>Skim253: /* Tasks Identified */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
Modeling & Structural Issues<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
<br />
Permission & Behavior Issues<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
<br />
== Proposed Solution ==<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT NOT NULL,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <code>OK</code> (action allowed), <code>Late</code> (action allowed with penalty), and <code>No</code> (action denied).<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_rights (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== DeadlineRight Model ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
# Permission checking methods<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
# Display methods<br />
def to_s<br />
name<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type, foreign_key: :deadline_type_id<br />
<br />
validates :due_at, presence: true<br />
validates :deadline_type_id, presence: true<br />
validates :parent, presence: true<br />
validates :round, numericality: { greater_than: 0 }, allow_nil: true<br />
<br />
# Scopes for common queries<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
scope :for_round, ->(round_num) { where(round: round_num) }<br />
scope :for_deadline_type, ->(type_name) { joins(:deadline_type).where(deadline_types: { name: type_name }) }<br />
<br />
# Instance methods replace class methods<br />
def copy(to_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
<br />
def set(deadline_type_id, parent_id, round)<br />
self.deadline_type_id = deadline_type_id<br />
self.parent_id = parent_id<br />
self.round = round<br />
save!<br />
end<br />
<br />
# Check if this deadline has passed<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
# Check if this deadline is upcoming<br />
def upcoming?<br />
due_at > Time.current<br />
end<br />
<br />
# Get the deadline type name<br />
def deadline_type_name<br />
deadline_type&.name<br />
end<br />
<br />
# Comparison method for sorting<br />
def <=>(other)<br />
return nil unless other.is_a?(DueDate)<br />
due_at <=> other.due_at<br />
end<br />
<br />
# Class methods for collection operations<br />
class << self<br />
def sort_due_dates(due_dates)<br />
due_dates.sort_by(&:due_at)<br />
end<br />
<br />
def any_future_due_dates?(due_dates)<br />
due_dates.any?(&:upcoming?)<br />
end<br />
<br />
def copy(from_assignment_id, to_assignment_id)<br />
from_assignment = Assignment.find(from_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
<br />
from_assignment.due_dates.each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
<br />
private<br />
<br />
before_save :set_default_round<br />
<br />
def set_default_round<br />
self.round ||= 1<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 5. DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Examples ===<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Validation with multiple assertions<br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: nil,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: 0<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on round field' do<br />
due_date.valid?<br />
expect(due_date.errors[:round]).to be_present<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
let(:due_date) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: nil<br />
)<br />
end<br />
<br />
it 'is valid' do<br />
expect(due_date).to be_valid<br />
end<br />
<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
<br />
# Scope with edge cases<br />
describe '.upcoming' do<br />
it 'returns only future due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to contain_exactly(upcoming_due_date1, upcoming_due_date2)<br />
end<br />
<br />
it 'orders results by due_at ascending' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to eq([upcoming_due_date1, upcoming_due_date2])<br />
end<br />
<br />
it 'excludes past due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).not_to include(past_due_date)<br />
end<br />
<br />
context 'when all due dates are in the past' do<br />
before do<br />
DueDate.destroy_all<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 3.days.ago,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'returns empty collection' do<br />
expect(DueDate.upcoming).to be_empty<br />
end<br />
end<br />
end<br />
<br />
# Instance method with error handling<br />
describe '#copy' do<br />
let(:original) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: late_right.id,<br />
round: 1<br />
)<br />
end<br />
<br />
let(:copied) { original.copy(assignment2.id) }<br />
<br />
it 'creates a new persisted record' do<br />
expect(copied).to be_persisted<br />
end<br />
<br />
it 'has different id from original' do<br />
expect(copied.id).not_to eq(original.id)<br />
end<br />
<br />
it 'preserves all attributes' do<br />
expect(copied.due_at).to eq(original.due_at)<br />
expect(copied.deadline_type_id).to eq(original.deadline_type_id)<br />
expect(copied.round).to eq(original.round)<br />
end<br />
<br />
context 'when copying to non-existent assignment' do<br />
it 'raises error' do<br />
expect do<br />
original.copy(99999)<br />
end.to raise_error(ActiveRecord::RecordNotFound)<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''DueDate model''': 60+ examples covering all methods and edge cases<br />
* '''Context depth''': 2-3 levels for complex scenarios<br />
* '''Code coverage''': 100% coverage of DueDate model methods<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167189
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T03:52:01Z
<p>Skim253: /* Motivation */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
Modeling & Structural Issues<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# Incomplete deadline type definitions - <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# No clear separation of concerns - data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
Permission & Behavior Issues<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
<br />
=== Tasks Identified ===<br />
<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
<br />
== Proposed Solution ==<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT NOT NULL,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <code>OK</code> (action allowed), <code>Late</code> (action allowed with penalty), and <code>No</code> (action denied).<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_rights (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== DeadlineRight Model ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
# Permission checking methods<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
# Display methods<br />
def to_s<br />
name<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type, foreign_key: :deadline_type_id<br />
<br />
validates :due_at, presence: true<br />
validates :deadline_type_id, presence: true<br />
validates :parent, presence: true<br />
validates :round, numericality: { greater_than: 0 }, allow_nil: true<br />
<br />
# Scopes for common queries<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
scope :for_round, ->(round_num) { where(round: round_num) }<br />
scope :for_deadline_type, ->(type_name) { joins(:deadline_type).where(deadline_types: { name: type_name }) }<br />
<br />
# Instance methods replace class methods<br />
def copy(to_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
<br />
def set(deadline_type_id, parent_id, round)<br />
self.deadline_type_id = deadline_type_id<br />
self.parent_id = parent_id<br />
self.round = round<br />
save!<br />
end<br />
<br />
# Check if this deadline has passed<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
# Check if this deadline is upcoming<br />
def upcoming?<br />
due_at > Time.current<br />
end<br />
<br />
# Get the deadline type name<br />
def deadline_type_name<br />
deadline_type&.name<br />
end<br />
<br />
# Comparison method for sorting<br />
def <=>(other)<br />
return nil unless other.is_a?(DueDate)<br />
due_at <=> other.due_at<br />
end<br />
<br />
# Class methods for collection operations<br />
class << self<br />
def sort_due_dates(due_dates)<br />
due_dates.sort_by(&:due_at)<br />
end<br />
<br />
def any_future_due_dates?(due_dates)<br />
due_dates.any?(&:upcoming?)<br />
end<br />
<br />
def copy(from_assignment_id, to_assignment_id)<br />
from_assignment = Assignment.find(from_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
<br />
from_assignment.due_dates.each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
<br />
private<br />
<br />
before_save :set_default_round<br />
<br />
def set_default_round<br />
self.round ||= 1<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 5. DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Examples ===<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Validation with multiple assertions<br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: nil,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: 0<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on round field' do<br />
due_date.valid?<br />
expect(due_date.errors[:round]).to be_present<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
let(:due_date) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: nil<br />
)<br />
end<br />
<br />
it 'is valid' do<br />
expect(due_date).to be_valid<br />
end<br />
<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
<br />
# Scope with edge cases<br />
describe '.upcoming' do<br />
it 'returns only future due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to contain_exactly(upcoming_due_date1, upcoming_due_date2)<br />
end<br />
<br />
it 'orders results by due_at ascending' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to eq([upcoming_due_date1, upcoming_due_date2])<br />
end<br />
<br />
it 'excludes past due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).not_to include(past_due_date)<br />
end<br />
<br />
context 'when all due dates are in the past' do<br />
before do<br />
DueDate.destroy_all<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 3.days.ago,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'returns empty collection' do<br />
expect(DueDate.upcoming).to be_empty<br />
end<br />
end<br />
end<br />
<br />
# Instance method with error handling<br />
describe '#copy' do<br />
let(:original) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: late_right.id,<br />
round: 1<br />
)<br />
end<br />
<br />
let(:copied) { original.copy(assignment2.id) }<br />
<br />
it 'creates a new persisted record' do<br />
expect(copied).to be_persisted<br />
end<br />
<br />
it 'has different id from original' do<br />
expect(copied.id).not_to eq(original.id)<br />
end<br />
<br />
it 'preserves all attributes' do<br />
expect(copied.due_at).to eq(original.due_at)<br />
expect(copied.deadline_type_id).to eq(original.deadline_type_id)<br />
expect(copied.round).to eq(original.round)<br />
end<br />
<br />
context 'when copying to non-existent assignment' do<br />
it 'raises error' do<br />
expect do<br />
original.copy(99999)<br />
end.to raise_error(ActiveRecord::RecordNotFound)<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''DueDate model''': 60+ examples covering all methods and edge cases<br />
* '''Context depth''': 2-3 levels for complex scenarios<br />
* '''Code coverage''': 100% coverage of DueDate model methods<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167182
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T00:27:39Z
<p>Skim253: /* Tasks Identified */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
=== Tasks Identified ===<br />
<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
<br />
== Proposed Solution ==<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT NOT NULL,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <code>OK</code> (action allowed), <code>Late</code> (action allowed with penalty), and <code>No</code> (action denied).<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_rights (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== DeadlineRight Model ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
# Permission checking methods<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
# Display methods<br />
def to_s<br />
name<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type, foreign_key: :deadline_type_id<br />
<br />
validates :due_at, presence: true<br />
validates :deadline_type_id, presence: true<br />
validates :parent, presence: true<br />
validates :round, numericality: { greater_than: 0 }, allow_nil: true<br />
<br />
# Scopes for common queries<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
scope :for_round, ->(round_num) { where(round: round_num) }<br />
scope :for_deadline_type, ->(type_name) { joins(:deadline_type).where(deadline_types: { name: type_name }) }<br />
<br />
# Instance methods replace class methods<br />
def copy(to_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
<br />
def set(deadline_type_id, parent_id, round)<br />
self.deadline_type_id = deadline_type_id<br />
self.parent_id = parent_id<br />
self.round = round<br />
save!<br />
end<br />
<br />
# Check if this deadline has passed<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
# Check if this deadline is upcoming<br />
def upcoming?<br />
due_at > Time.current<br />
end<br />
<br />
# Get the deadline type name<br />
def deadline_type_name<br />
deadline_type&.name<br />
end<br />
<br />
# Comparison method for sorting<br />
def <=>(other)<br />
return nil unless other.is_a?(DueDate)<br />
due_at <=> other.due_at<br />
end<br />
<br />
# Class methods for collection operations<br />
class << self<br />
def sort_due_dates(due_dates)<br />
due_dates.sort_by(&:due_at)<br />
end<br />
<br />
def any_future_due_dates?(due_dates)<br />
due_dates.any?(&:upcoming?)<br />
end<br />
<br />
def copy(from_assignment_id, to_assignment_id)<br />
from_assignment = Assignment.find(from_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
<br />
from_assignment.due_dates.each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
<br />
private<br />
<br />
before_save :set_default_round<br />
<br />
def set_default_round<br />
self.round ||= 1<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 5. DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Examples ===<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Validation with multiple assertions<br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: nil,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: 0<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on round field' do<br />
due_date.valid?<br />
expect(due_date.errors[:round]).to be_present<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
let(:due_date) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: nil<br />
)<br />
end<br />
<br />
it 'is valid' do<br />
expect(due_date).to be_valid<br />
end<br />
<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
<br />
# Scope with edge cases<br />
describe '.upcoming' do<br />
it 'returns only future due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to contain_exactly(upcoming_due_date1, upcoming_due_date2)<br />
end<br />
<br />
it 'orders results by due_at ascending' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to eq([upcoming_due_date1, upcoming_due_date2])<br />
end<br />
<br />
it 'excludes past due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).not_to include(past_due_date)<br />
end<br />
<br />
context 'when all due dates are in the past' do<br />
before do<br />
DueDate.destroy_all<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 3.days.ago,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'returns empty collection' do<br />
expect(DueDate.upcoming).to be_empty<br />
end<br />
end<br />
end<br />
<br />
# Instance method with error handling<br />
describe '#copy' do<br />
let(:original) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: late_right.id,<br />
round: 1<br />
)<br />
end<br />
<br />
let(:copied) { original.copy(assignment2.id) }<br />
<br />
it 'creates a new persisted record' do<br />
expect(copied).to be_persisted<br />
end<br />
<br />
it 'has different id from original' do<br />
expect(copied.id).not_to eq(original.id)<br />
end<br />
<br />
it 'preserves all attributes' do<br />
expect(copied.due_at).to eq(original.due_at)<br />
expect(copied.deadline_type_id).to eq(original.deadline_type_id)<br />
expect(copied.round).to eq(original.round)<br />
end<br />
<br />
context 'when copying to non-existent assignment' do<br />
it 'raises error' do<br />
expect do<br />
original.copy(99999)<br />
end.to raise_error(ActiveRecord::RecordNotFound)<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''DueDate model''': 60+ examples covering all methods and edge cases<br />
* '''Context depth''': 2-3 levels for complex scenarios<br />
* '''Code coverage''': 100% coverage of DueDate model methods<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167181
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T00:27:13Z
<p>Skim253: </p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
=== Tasks Identified ===<br />
<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Update controllers and APIs to use the new mixin-based approach for consistent permission checks and deadline queries.<br />
<br />
<br />
== Proposed Solution ==<br />
<br />
[[File:Duedate-diagram.png|600px]]<br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT NOT NULL,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <code>OK</code> (action allowed), <code>Late</code> (action allowed with penalty), and <code>No</code> (action denied).<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_rights (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== DeadlineRight Model ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
# Permission checking methods<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
# Display methods<br />
def to_s<br />
name<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type, foreign_key: :deadline_type_id<br />
<br />
validates :due_at, presence: true<br />
validates :deadline_type_id, presence: true<br />
validates :parent, presence: true<br />
validates :round, numericality: { greater_than: 0 }, allow_nil: true<br />
<br />
# Scopes for common queries<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
scope :for_round, ->(round_num) { where(round: round_num) }<br />
scope :for_deadline_type, ->(type_name) { joins(:deadline_type).where(deadline_types: { name: type_name }) }<br />
<br />
# Instance methods replace class methods<br />
def copy(to_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
<br />
def set(deadline_type_id, parent_id, round)<br />
self.deadline_type_id = deadline_type_id<br />
self.parent_id = parent_id<br />
self.round = round<br />
save!<br />
end<br />
<br />
# Check if this deadline has passed<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
# Check if this deadline is upcoming<br />
def upcoming?<br />
due_at > Time.current<br />
end<br />
<br />
# Get the deadline type name<br />
def deadline_type_name<br />
deadline_type&.name<br />
end<br />
<br />
# Comparison method for sorting<br />
def <=>(other)<br />
return nil unless other.is_a?(DueDate)<br />
due_at <=> other.due_at<br />
end<br />
<br />
# Class methods for collection operations<br />
class << self<br />
def sort_due_dates(due_dates)<br />
due_dates.sort_by(&:due_at)<br />
end<br />
<br />
def any_future_due_dates?(due_dates)<br />
due_dates.any?(&:upcoming?)<br />
end<br />
<br />
def copy(from_assignment_id, to_assignment_id)<br />
from_assignment = Assignment.find(from_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
<br />
from_assignment.due_dates.each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
<br />
private<br />
<br />
before_save :set_default_round<br />
<br />
def set_default_round<br />
self.round ||= 1<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 5. DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Examples ===<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Validation with multiple assertions<br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: nil,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: 0<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on round field' do<br />
due_date.valid?<br />
expect(due_date.errors[:round]).to be_present<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
let(:due_date) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: nil<br />
)<br />
end<br />
<br />
it 'is valid' do<br />
expect(due_date).to be_valid<br />
end<br />
<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
<br />
# Scope with edge cases<br />
describe '.upcoming' do<br />
it 'returns only future due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to contain_exactly(upcoming_due_date1, upcoming_due_date2)<br />
end<br />
<br />
it 'orders results by due_at ascending' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to eq([upcoming_due_date1, upcoming_due_date2])<br />
end<br />
<br />
it 'excludes past due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).not_to include(past_due_date)<br />
end<br />
<br />
context 'when all due dates are in the past' do<br />
before do<br />
DueDate.destroy_all<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 3.days.ago,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'returns empty collection' do<br />
expect(DueDate.upcoming).to be_empty<br />
end<br />
end<br />
end<br />
<br />
# Instance method with error handling<br />
describe '#copy' do<br />
let(:original) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: late_right.id,<br />
round: 1<br />
)<br />
end<br />
<br />
let(:copied) { original.copy(assignment2.id) }<br />
<br />
it 'creates a new persisted record' do<br />
expect(copied).to be_persisted<br />
end<br />
<br />
it 'has different id from original' do<br />
expect(copied.id).not_to eq(original.id)<br />
end<br />
<br />
it 'preserves all attributes' do<br />
expect(copied.due_at).to eq(original.due_at)<br />
expect(copied.deadline_type_id).to eq(original.deadline_type_id)<br />
expect(copied.round).to eq(original.round)<br />
end<br />
<br />
context 'when copying to non-existent assignment' do<br />
it 'raises error' do<br />
expect do<br />
original.copy(99999)<br />
end.to raise_error(ActiveRecord::RecordNotFound)<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''DueDate model''': 60+ examples covering all methods and edge cases<br />
* '''Context depth''': 2-3 levels for complex scenarios<br />
* '''Code coverage''': 100% coverage of DueDate model methods<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=File:Duedate-diagram.png&diff=167180
File:Duedate-diagram.png
2025-12-02T00:26:12Z
<p>Skim253: </p>
<hr />
<div></div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167179
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T00:16:22Z
<p>Skim253: </p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
=== Tasks Identified ===<br />
<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Update controllers and APIs to use the new mixin-based approach for consistent permission checks and deadline queries.<br />
<br />
<br />
== Proposed Solution ==<br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT NOT NULL,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <code>OK</code> (action allowed), <code>Late</code> (action allowed with penalty), and <code>No</code> (action denied).<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_rights (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== DeadlineRight Model ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
# Permission checking methods<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
# Display methods<br />
def to_s<br />
name<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type, foreign_key: :deadline_type_id<br />
<br />
validates :due_at, presence: true<br />
validates :deadline_type_id, presence: true<br />
validates :parent, presence: true<br />
validates :round, numericality: { greater_than: 0 }, allow_nil: true<br />
<br />
# Scopes for common queries<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
scope :for_round, ->(round_num) { where(round: round_num) }<br />
scope :for_deadline_type, ->(type_name) { joins(:deadline_type).where(deadline_types: { name: type_name }) }<br />
<br />
# Instance methods replace class methods<br />
def copy(to_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
<br />
def set(deadline_type_id, parent_id, round)<br />
self.deadline_type_id = deadline_type_id<br />
self.parent_id = parent_id<br />
self.round = round<br />
save!<br />
end<br />
<br />
# Check if this deadline has passed<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
# Check if this deadline is upcoming<br />
def upcoming?<br />
due_at > Time.current<br />
end<br />
<br />
# Get the deadline type name<br />
def deadline_type_name<br />
deadline_type&.name<br />
end<br />
<br />
# Comparison method for sorting<br />
def <=>(other)<br />
return nil unless other.is_a?(DueDate)<br />
due_at <=> other.due_at<br />
end<br />
<br />
# Class methods for collection operations<br />
class << self<br />
def sort_due_dates(due_dates)<br />
due_dates.sort_by(&:due_at)<br />
end<br />
<br />
def any_future_due_dates?(due_dates)<br />
due_dates.any?(&:upcoming?)<br />
end<br />
<br />
def copy(from_assignment_id, to_assignment_id)<br />
from_assignment = Assignment.find(from_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
<br />
from_assignment.due_dates.each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
<br />
private<br />
<br />
before_save :set_default_round<br />
<br />
def set_default_round<br />
self.round ||= 1<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 5. DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Examples ===<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Validation with multiple assertions<br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: nil,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: 0<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on round field' do<br />
due_date.valid?<br />
expect(due_date.errors[:round]).to be_present<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
let(:due_date) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: nil<br />
)<br />
end<br />
<br />
it 'is valid' do<br />
expect(due_date).to be_valid<br />
end<br />
<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
<br />
# Scope with edge cases<br />
describe '.upcoming' do<br />
it 'returns only future due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to contain_exactly(upcoming_due_date1, upcoming_due_date2)<br />
end<br />
<br />
it 'orders results by due_at ascending' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to eq([upcoming_due_date1, upcoming_due_date2])<br />
end<br />
<br />
it 'excludes past due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).not_to include(past_due_date)<br />
end<br />
<br />
context 'when all due dates are in the past' do<br />
before do<br />
DueDate.destroy_all<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 3.days.ago,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'returns empty collection' do<br />
expect(DueDate.upcoming).to be_empty<br />
end<br />
end<br />
end<br />
<br />
# Instance method with error handling<br />
describe '#copy' do<br />
let(:original) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: late_right.id,<br />
round: 1<br />
)<br />
end<br />
<br />
let(:copied) { original.copy(assignment2.id) }<br />
<br />
it 'creates a new persisted record' do<br />
expect(copied).to be_persisted<br />
end<br />
<br />
it 'has different id from original' do<br />
expect(copied.id).not_to eq(original.id)<br />
end<br />
<br />
it 'preserves all attributes' do<br />
expect(copied.due_at).to eq(original.due_at)<br />
expect(copied.deadline_type_id).to eq(original.deadline_type_id)<br />
expect(copied.round).to eq(original.round)<br />
end<br />
<br />
context 'when copying to non-existent assignment' do<br />
it 'raises error' do<br />
expect do<br />
original.copy(99999)<br />
end.to raise_error(ActiveRecord::RecordNotFound)<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''DueDate model''': 60+ examples covering all methods and edge cases<br />
* '''Context depth''': 2-3 levels for complex scenarios<br />
* '''Code coverage''': 100% coverage of DueDate model methods<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167178
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T00:14:52Z
<p>Skim253: </p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
=== Tasks Identified ===<br />
<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Update controllers and APIs to use the new mixin-based approach for consistent permission checks and deadline queries.<br />
<br />
<br />
== Proposed Solution ==<br />
<br />
=== DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT NOT NULL,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
# same code for review, teammate_review, quiz, team_formation, signup, drop_topic <br />
end<br />
</syntaxhighlight><br />
<br />
=== DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <code>OK</code> (action allowed), <code>Late</code> (action allowed with penalty), and <code>No</code> (action denied).<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_rights (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== DeadlineRight Model ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
# Permission checking methods<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
# Display methods<br />
def to_s<br />
name<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type, foreign_key: :deadline_type_id<br />
<br />
validates :due_at, presence: true<br />
validates :deadline_type_id, presence: true<br />
validates :parent, presence: true<br />
validates :round, numericality: { greater_than: 0 }, allow_nil: true<br />
<br />
# Scopes for common queries<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
scope :for_round, ->(round_num) { where(round: round_num) }<br />
scope :for_deadline_type, ->(type_name) { joins(:deadline_type).where(deadline_types: { name: type_name }) }<br />
<br />
# Instance methods replace class methods<br />
def copy(to_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
<br />
def set(deadline_type_id, parent_id, round)<br />
self.deadline_type_id = deadline_type_id<br />
self.parent_id = parent_id<br />
self.round = round<br />
save!<br />
end<br />
<br />
# Check if this deadline has passed<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
# Check if this deadline is upcoming<br />
def upcoming?<br />
due_at > Time.current<br />
end<br />
<br />
# Get the deadline type name<br />
def deadline_type_name<br />
deadline_type&.name<br />
end<br />
<br />
# Comparison method for sorting<br />
def <=>(other)<br />
return nil unless other.is_a?(DueDate)<br />
due_at <=> other.due_at<br />
end<br />
<br />
# Class methods for collection operations<br />
class << self<br />
def sort_due_dates(due_dates)<br />
due_dates.sort_by(&:due_at)<br />
end<br />
<br />
def any_future_due_dates?(due_dates)<br />
due_dates.any?(&:upcoming?)<br />
end<br />
<br />
def copy(from_assignment_id, to_assignment_id)<br />
from_assignment = Assignment.find(from_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
<br />
from_assignment.due_dates.each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
<br />
private<br />
<br />
before_save :set_default_round<br />
<br />
def set_default_round<br />
self.round ||= 1<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 5. DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Examples ===<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Validation with multiple assertions<br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: nil,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: 0<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on round field' do<br />
due_date.valid?<br />
expect(due_date.errors[:round]).to be_present<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
let(:due_date) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: nil<br />
)<br />
end<br />
<br />
it 'is valid' do<br />
expect(due_date).to be_valid<br />
end<br />
<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
<br />
# Scope with edge cases<br />
describe '.upcoming' do<br />
it 'returns only future due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to contain_exactly(upcoming_due_date1, upcoming_due_date2)<br />
end<br />
<br />
it 'orders results by due_at ascending' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to eq([upcoming_due_date1, upcoming_due_date2])<br />
end<br />
<br />
it 'excludes past due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).not_to include(past_due_date)<br />
end<br />
<br />
context 'when all due dates are in the past' do<br />
before do<br />
DueDate.destroy_all<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 3.days.ago,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'returns empty collection' do<br />
expect(DueDate.upcoming).to be_empty<br />
end<br />
end<br />
end<br />
<br />
# Instance method with error handling<br />
describe '#copy' do<br />
let(:original) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: late_right.id,<br />
round: 1<br />
)<br />
end<br />
<br />
let(:copied) { original.copy(assignment2.id) }<br />
<br />
it 'creates a new persisted record' do<br />
expect(copied).to be_persisted<br />
end<br />
<br />
it 'has different id from original' do<br />
expect(copied.id).not_to eq(original.id)<br />
end<br />
<br />
it 'preserves all attributes' do<br />
expect(copied.due_at).to eq(original.due_at)<br />
expect(copied.deadline_type_id).to eq(original.deadline_type_id)<br />
expect(copied.round).to eq(original.round)<br />
end<br />
<br />
context 'when copying to non-existent assignment' do<br />
it 'raises error' do<br />
expect do<br />
original.copy(99999)<br />
end.to raise_error(ActiveRecord::RecordNotFound)<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''DueDate model''': 60+ examples covering all methods and edge cases<br />
* '''Context depth''': 2-3 levels for complex scenarios<br />
* '''Code coverage''': 100% coverage of DueDate model methods<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Semantic Helpers''': Methods like <code>submission?</code>, <code>allows_action?</code> improve code readability<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167177
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T00:11:51Z
<p>Skim253: </p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
=== Tasks Identified ===<br />
<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Update controllers and APIs to use the new mixin-based approach for consistent permission checks and deadline queries.<br />
<br />
<br />
== Proposed Solution ==<br />
<br />
=== 1. DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT NOT NULL,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
<br />
def review?<br />
name == 'review'<br />
end<br />
<br />
def teammate_review?<br />
name == 'teammate_review'<br />
end<br />
<br />
def quiz?<br />
name == 'quiz'<br />
end<br />
<br />
def team_formation?<br />
name == 'team_formation'<br />
end<br />
<br />
def signup?<br />
name == 'signup'<br />
end<br />
<br />
def drop_topic?<br />
name == 'drop_topic'<br />
end<br />
<br />
# Display methods<br />
def display_name<br />
name.humanize<br />
end<br />
<br />
def to_s<br />
display_name<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== 2. DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <code>OK</code> (action allowed), <code>Late</code> (action allowed with penalty), and <code>No</code> (action denied).<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_rights (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== DeadlineRight Model ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
# Permission checking methods<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
# Display methods<br />
def to_s<br />
name<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 3. DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type, foreign_key: :deadline_type_id<br />
<br />
validates :due_at, presence: true<br />
validates :deadline_type_id, presence: true<br />
validates :parent, presence: true<br />
validates :round, numericality: { greater_than: 0 }, allow_nil: true<br />
<br />
# Scopes for common queries<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
scope :for_round, ->(round_num) { where(round: round_num) }<br />
scope :for_deadline_type, ->(type_name) { joins(:deadline_type).where(deadline_types: { name: type_name }) }<br />
<br />
# Instance methods replace class methods<br />
def copy(to_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
<br />
def set(deadline_type_id, parent_id, round)<br />
self.deadline_type_id = deadline_type_id<br />
self.parent_id = parent_id<br />
self.round = round<br />
save!<br />
end<br />
<br />
# Check if this deadline has passed<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
# Check if this deadline is upcoming<br />
def upcoming?<br />
due_at > Time.current<br />
end<br />
<br />
# Get the deadline type name<br />
def deadline_type_name<br />
deadline_type&.name<br />
end<br />
<br />
# Comparison method for sorting<br />
def <=>(other)<br />
return nil unless other.is_a?(DueDate)<br />
due_at <=> other.due_at<br />
end<br />
<br />
# Class methods for collection operations<br />
class << self<br />
def sort_due_dates(due_dates)<br />
due_dates.sort_by(&:due_at)<br />
end<br />
<br />
def any_future_due_dates?(due_dates)<br />
due_dates.any?(&:upcoming?)<br />
end<br />
<br />
def copy(from_assignment_id, to_assignment_id)<br />
from_assignment = Assignment.find(from_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
<br />
from_assignment.due_dates.each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
<br />
private<br />
<br />
before_save :set_default_round<br />
<br />
def set_default_round<br />
self.round ||= 1<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 4. Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 5. DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Examples ===<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Validation with multiple assertions<br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: nil,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: 0<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on round field' do<br />
due_date.valid?<br />
expect(due_date.errors[:round]).to be_present<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
let(:due_date) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: nil<br />
)<br />
end<br />
<br />
it 'is valid' do<br />
expect(due_date).to be_valid<br />
end<br />
<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
<br />
# Scope with edge cases<br />
describe '.upcoming' do<br />
it 'returns only future due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to contain_exactly(upcoming_due_date1, upcoming_due_date2)<br />
end<br />
<br />
it 'orders results by due_at ascending' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to eq([upcoming_due_date1, upcoming_due_date2])<br />
end<br />
<br />
it 'excludes past due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).not_to include(past_due_date)<br />
end<br />
<br />
context 'when all due dates are in the past' do<br />
before do<br />
DueDate.destroy_all<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 3.days.ago,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'returns empty collection' do<br />
expect(DueDate.upcoming).to be_empty<br />
end<br />
end<br />
end<br />
<br />
# Instance method with error handling<br />
describe '#copy' do<br />
let(:original) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: late_right.id,<br />
round: 1<br />
)<br />
end<br />
<br />
let(:copied) { original.copy(assignment2.id) }<br />
<br />
it 'creates a new persisted record' do<br />
expect(copied).to be_persisted<br />
end<br />
<br />
it 'has different id from original' do<br />
expect(copied.id).not_to eq(original.id)<br />
end<br />
<br />
it 'preserves all attributes' do<br />
expect(copied.due_at).to eq(original.due_at)<br />
expect(copied.deadline_type_id).to eq(original.deadline_type_id)<br />
expect(copied.round).to eq(original.round)<br />
end<br />
<br />
context 'when copying to non-existent assignment' do<br />
it 'raises error' do<br />
expect do<br />
original.copy(99999)<br />
end.to raise_error(ActiveRecord::RecordNotFound)<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''DueDate model''': 60+ examples covering all methods and edge cases<br />
* '''Context depth''': 2-3 levels for complex scenarios<br />
* '''Code coverage''': 100% coverage of DueDate model methods<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Semantic Helpers''': Methods like <code>submission?</code>, <code>allows_action?</code> improve code readability<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167176
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T00:11:03Z
<p>Skim253: </p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
=== Tasks Identified ===<br />
<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Update controllers and APIs to use the new mixin-based approach for consistent permission checks and deadline queries.<br />
<br />
<br />
== Proposed Solution ==<br />
<br />
=== 1. DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT NOT NULL,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
<br />
def review?<br />
name == 'review'<br />
end<br />
<br />
def teammate_review?<br />
name == 'teammate_review'<br />
end<br />
<br />
def quiz?<br />
name == 'quiz'<br />
end<br />
<br />
def team_formation?<br />
name == 'team_formation'<br />
end<br />
<br />
def signup?<br />
name == 'signup'<br />
end<br />
<br />
def drop_topic?<br />
name == 'drop_topic'<br />
end<br />
<br />
# Display methods<br />
def display_name<br />
name.humanize<br />
end<br />
<br />
def to_s<br />
display_name<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== 2. DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <code>OK</code> (action allowed), <code>Late</code> (action allowed with penalty), and <code>No</code> (action denied).<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_rights (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== DeadlineRight Model ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
# Permission checking methods<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
# Display methods<br />
def to_s<br />
name<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 3. DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type, foreign_key: :deadline_type_id<br />
<br />
validates :due_at, presence: true<br />
validates :deadline_type_id, presence: true<br />
validates :parent, presence: true<br />
validates :round, numericality: { greater_than: 0 }, allow_nil: true<br />
<br />
# Scopes for common queries<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
scope :for_round, ->(round_num) { where(round: round_num) }<br />
scope :for_deadline_type, ->(type_name) { joins(:deadline_type).where(deadline_types: { name: type_name }) }<br />
<br />
# Instance methods replace class methods<br />
def copy(to_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
<br />
def set(deadline_type_id, parent_id, round)<br />
self.deadline_type_id = deadline_type_id<br />
self.parent_id = parent_id<br />
self.round = round<br />
save!<br />
end<br />
<br />
# Check if this deadline has passed<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
# Check if this deadline is upcoming<br />
def upcoming?<br />
due_at > Time.current<br />
end<br />
<br />
# Get the deadline type name<br />
def deadline_type_name<br />
deadline_type&.name<br />
end<br />
<br />
# Comparison method for sorting<br />
def <=>(other)<br />
return nil unless other.is_a?(DueDate)<br />
due_at <=> other.due_at<br />
end<br />
<br />
# Class methods for collection operations<br />
class << self<br />
def sort_due_dates(due_dates)<br />
due_dates.sort_by(&:due_at)<br />
end<br />
<br />
def any_future_due_dates?(due_dates)<br />
due_dates.any?(&:upcoming?)<br />
end<br />
<br />
def copy(from_assignment_id, to_assignment_id)<br />
from_assignment = Assignment.find(from_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
<br />
from_assignment.due_dates.each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
<br />
private<br />
<br />
before_save :set_default_round<br />
<br />
def set_default_round<br />
self.round ||= 1<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 4. Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 5. DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Examples ===<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Validation with multiple assertions<br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: nil,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: 0<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on round field' do<br />
due_date.valid?<br />
expect(due_date.errors[:round]).to be_present<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
let(:due_date) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: nil<br />
)<br />
end<br />
<br />
it 'is valid' do<br />
expect(due_date).to be_valid<br />
end<br />
<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
<br />
# Scope with edge cases<br />
describe '.upcoming' do<br />
it 'returns only future due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to contain_exactly(upcoming_due_date1, upcoming_due_date2)<br />
end<br />
<br />
it 'orders results by due_at ascending' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to eq([upcoming_due_date1, upcoming_due_date2])<br />
end<br />
<br />
it 'excludes past due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).not_to include(past_due_date)<br />
end<br />
<br />
context 'when all due dates are in the past' do<br />
before do<br />
DueDate.destroy_all<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 3.days.ago,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'returns empty collection' do<br />
expect(DueDate.upcoming).to be_empty<br />
end<br />
end<br />
end<br />
<br />
# Instance method with error handling<br />
describe '#copy' do<br />
let(:original) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: late_right.id,<br />
round: 1<br />
)<br />
end<br />
<br />
let(:copied) { original.copy(assignment2.id) }<br />
<br />
it 'creates a new persisted record' do<br />
expect(copied).to be_persisted<br />
end<br />
<br />
it 'has different id from original' do<br />
expect(copied.id).not_to eq(original.id)<br />
end<br />
<br />
it 'preserves all attributes' do<br />
expect(copied.due_at).to eq(original.due_at)<br />
expect(copied.deadline_type_id).to eq(original.deadline_type_id)<br />
expect(copied.round).to eq(original.round)<br />
end<br />
<br />
context 'when copying to non-existent assignment' do<br />
it 'raises error' do<br />
expect do<br />
original.copy(99999)<br />
end.to raise_error(ActiveRecord::RecordNotFound)<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''DueDate model''': 60+ examples covering all methods and edge cases<br />
* '''Context depth''': 2-3 levels for complex scenarios<br />
* '''Code coverage''': 100% coverage of DueDate model methods<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Semantic Helpers''': Methods like <code>submission?</code>, <code>allows_action?</code> improve code readability<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Semantic Helpers''': Methods like <code>submission?</code>, <code>allows_action?</code> improve code readability<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167175
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-02T00:09:11Z
<p>Skim253: /* Testing Plan */</p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
=== Tasks Identified ===<br />
<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Update controllers and APIs to use the new mixin-based approach for consistent permission checks and deadline queries.<br />
<br />
<br />
== Proposed Solution ==<br />
<br />
=== 1. DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT NOT NULL,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
<br />
def review?<br />
name == 'review'<br />
end<br />
<br />
def teammate_review?<br />
name == 'teammate_review'<br />
end<br />
<br />
def quiz?<br />
name == 'quiz'<br />
end<br />
<br />
def team_formation?<br />
name == 'team_formation'<br />
end<br />
<br />
def signup?<br />
name == 'signup'<br />
end<br />
<br />
def drop_topic?<br />
name == 'drop_topic'<br />
end<br />
<br />
# Display methods<br />
def display_name<br />
name.humanize<br />
end<br />
<br />
def to_s<br />
display_name<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== 2. DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <code>OK</code> (action allowed), <code>Late</code> (action allowed with penalty), and <code>No</code> (action denied).<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_rights (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== DeadlineRight Model ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
# Permission checking methods<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
# Display methods<br />
def to_s<br />
name<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 3. DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type, foreign_key: :deadline_type_id<br />
<br />
validates :due_at, presence: true<br />
validates :deadline_type_id, presence: true<br />
validates :parent, presence: true<br />
validates :round, numericality: { greater_than: 0 }, allow_nil: true<br />
<br />
# Scopes for common queries<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
scope :for_round, ->(round_num) { where(round: round_num) }<br />
scope :for_deadline_type, ->(type_name) { joins(:deadline_type).where(deadline_types: { name: type_name }) }<br />
<br />
# Instance methods replace class methods<br />
def copy(to_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
<br />
def set(deadline_type_id, parent_id, round)<br />
self.deadline_type_id = deadline_type_id<br />
self.parent_id = parent_id<br />
self.round = round<br />
save!<br />
end<br />
<br />
# Check if this deadline has passed<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
# Check if this deadline is upcoming<br />
def upcoming?<br />
due_at > Time.current<br />
end<br />
<br />
# Get the deadline type name<br />
def deadline_type_name<br />
deadline_type&.name<br />
end<br />
<br />
# Comparison method for sorting<br />
def <=>(other)<br />
return nil unless other.is_a?(DueDate)<br />
due_at <=> other.due_at<br />
end<br />
<br />
# Class methods for collection operations<br />
class << self<br />
def sort_due_dates(due_dates)<br />
due_dates.sort_by(&:due_at)<br />
end<br />
<br />
def any_future_due_dates?(due_dates)<br />
due_dates.any?(&:upcoming?)<br />
end<br />
<br />
def copy(from_assignment_id, to_assignment_id)<br />
from_assignment = Assignment.find(from_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
<br />
from_assignment.due_dates.each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
<br />
private<br />
<br />
before_save :set_default_round<br />
<br />
def set_default_round<br />
self.round ||= 1<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 4. Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 5. DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 6. Controller and API Updates ===<br />
<br />
Controllers can now use the new unified mixins for permission checks and deadline queries.<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDatesController < ApplicationController<br />
def can_perform_action<br />
assignment = Assignment.find(params[:assignment_id])<br />
participant = current_user.participant_for(assignment)<br />
current_due_date = assignment.next_due_date(params[:topic_id])<br />
<br />
action = params[:action_type].to_sym<br />
allowed = case action<br />
when :submit then current_due_date&.can_submit?(participant)<br />
when :review then current_due_date&.can_review?(participant)<br />
when :quiz then current_due_date&.can_take_quiz?(participant)<br />
else false<br />
end<br />
<br />
render json: { allowed: allowed, current_stage: assignment.current_stage }<br />
end<br />
<br />
def upcoming_deadlines<br />
assignment = Assignment.find(params[:assignment_id])<br />
deadlines = assignment.due_dates.upcoming.limit(5)<br />
render json: deadlines<br />
end<br />
<br />
def current_stage<br />
assignment = Assignment.find(params[:assignment_id])<br />
render json: { <br />
stage: assignment.current_stage,<br />
next_deadline: assignment.next_due_date<br />
}<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== New Endpoints ====<br />
* <code>GET /assignments/:id/due_dates/permissions?action_type=submit</code> — Check if user can perform an action<br />
* <code>GET /assignments/:id/due_dates/upcoming</code> — Get upcoming deadlines <br />
* <code>GET /assignments/:id/due_dates/current_stage</code> — Get current stage and next deadline<br />
<br />
<br />
== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
=== Tasks Identified ===<br />
<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Update controllers and APIs to use the new mixin-based approach for consistent permission checks and deadline queries.<br />
<br />
<br />
== Proposed Solution ==<br />
<br />
=== 1. DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT NOT NULL,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
<br />
def review?<br />
name == 'review'<br />
end<br />
<br />
def teammate_review?<br />
name == 'teammate_review'<br />
end<br />
<br />
def quiz?<br />
name == 'quiz'<br />
end<br />
<br />
def team_formation?<br />
name == 'team_formation'<br />
end<br />
<br />
def signup?<br />
name == 'signup'<br />
end<br />
<br />
def drop_topic?<br />
name == 'drop_topic'<br />
end<br />
<br />
# Display methods<br />
def display_name<br />
name.humanize<br />
end<br />
<br />
def to_s<br />
display_name<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== 2. DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <code>OK</code> (action allowed), <code>Late</code> (action allowed with penalty), and <code>No</code> (action denied).<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_rights (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== DeadlineRight Model ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
# Permission checking methods<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
# Display methods<br />
def to_s<br />
name<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 3. DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Old implementation (class method)<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type, foreign_key: :deadline_type_id<br />
<br />
validates :due_at, presence: true<br />
validates :deadline_type_id, presence: true<br />
validates :parent, presence: true<br />
validates :round, numericality: { greater_than: 0 }, allow_nil: true<br />
<br />
# Scopes for common queries<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
scope :for_round, ->(round_num) { where(round: round_num) }<br />
scope :for_deadline_type, ->(type_name) { joins(:deadline_type).where(deadline_types: { name: type_name }) }<br />
<br />
# Instance methods replace class methods<br />
def copy(to_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
<br />
def set(deadline_type_id, parent_id, round)<br />
self.deadline_type_id = deadline_type_id<br />
self.parent_id = parent_id<br />
self.round = round<br />
save!<br />
end<br />
<br />
# Check if this deadline has passed<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
# Check if this deadline is upcoming<br />
def upcoming?<br />
due_at > Time.current<br />
end<br />
<br />
# Get the deadline type name<br />
def deadline_type_name<br />
deadline_type&.name<br />
end<br />
<br />
# Comparison method for sorting<br />
def <=>(other)<br />
return nil unless other.is_a?(DueDate)<br />
due_at <=> other.due_at<br />
end<br />
<br />
# Class methods for collection operations<br />
class << self<br />
def sort_due_dates(due_dates)<br />
due_dates.sort_by(&:due_at)<br />
end<br />
<br />
def any_future_due_dates?(due_dates)<br />
due_dates.any?(&:upcoming?)<br />
end<br />
<br />
def copy(from_assignment_id, to_assignment_id)<br />
from_assignment = Assignment.find(from_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
<br />
from_assignment.due_dates.each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
<br />
private<br />
<br />
before_save :set_default_round<br />
<br />
def set_default_round<br />
self.round ||= 1<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 4. Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 5. DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
<br />
<br />
== Testing ==<br />
<br />
The test suite includes comprehensive RSpec tests for the ''DueDate'' model and its associated models (''DeadlineType'', ''DeadlineRight'').<br />
These tests verify model validations, scopes, instance methods, class methods, and callbacks with extensive coverage of edge cases and error conditions.<br />
<br />
=== Test Structure ===<br />
<br />
The test suite follows RSpec best practices with:<br />
* '''Nested contexts''' for different scenarios (e.g., "when parent is missing", "when round is 0")<br />
* '''Multiple assertions per context''' to verify behavior from different angles<br />
* '''Edge case coverage''' including empty collections, nil values, and boundary conditions<br />
* '''Error case testing''' for invalid data and non-existent records<br />
* '''Clear descriptive names''' using "context 'when...'" and "it 'does something'" patterns<br />
<br />
=== Current Coverage ===<br />
<br />
==== Associations ====<br />
* Tests verify <code>belongs_to :parent</code> (polymorphic) and <code>belongs_to :deadline_type</code> relationships<br />
<br />
==== Validations ====<br />
* '''Required field validation''': Tests for parent, due_at, and deadline_type_id presence<br />
* '''Round validation''': Tests for positive values, zero rejection, negative rejection, and nil handling<br />
* '''Error messages''': Verifies specific error messages are added to appropriate fields<br />
* '''Valid record creation''': Confirms records persist when all requirements are met<br />
<br />
==== Scopes ====<br />
* '''<code>.upcoming</code>''': Returns future due dates ordered by due_at, excludes past dates, handles empty results<br />
* '''<code>.overdue</code>''': Returns past due dates ordered by due_at, excludes future dates, handles empty results<br />
* '''<code>.for_round</code>''': Filters by round number, handles non-existent rounds<br />
* '''<code>.for_deadline_type</code>''': Filters by deadline type name, handles non-existent types<br />
<br />
==== Instance Methods ====<br />
* '''<code>#overdue?</code>''': Tests past dates (true), future dates (false)<br />
* '''<code>#upcoming?</code>''': Tests future dates (true), past dates (false)<br />
* '''<code>#set</code>''': Verifies updating deadline_type_id, parent_id, and round with persistence and error handling<br />
* '''<code>#copy</code>''': Tests duplication to new assignment, attribute preservation, error handling for non-existent targets<br />
* '''<code>#deadline_type_name</code>''': Returns associated deadline type name, handles nil cases<br />
* '''<code>#last_deadline?</code>''': Tests detection of final deadline, handles multiple deadlines and single deadline scenarios<br />
* '''<code>#<=></code>''': Tests comparison by due_at time, handles non-DueDate objects<br />
<br />
==== Class Methods ====<br />
* '''<code>.sort_due_dates</code>''': Sorts by due_at ascending, handles empty arrays and single elements<br />
* '''<code>.any_future_due_dates?</code>''': Detects future dates in collections, handles empty arrays and mixed date collections<br />
* '''<code>.copy</code>''': Copies all due dates between assignments, preserves attributes, handles empty sources and non-existent records<br />
<br />
==== Callbacks ====<br />
* '''<code>before_save :set_default_round</code>''': Sets round to 1 when not specified, preserves explicit values, handles nil<br />
<br />
=== Test Examples ===<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Validation with multiple assertions<br />
describe 'validations' do<br />
context 'when parent is missing' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: nil,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on parent field' do<br />
due_date.valid?<br />
expect(due_date.errors[:parent]).to include('must exist')<br />
end<br />
end<br />
<br />
context 'when round validation' do<br />
context 'with round value of 0' do<br />
let(:due_date) do<br />
DueDate.new(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: 0<br />
)<br />
end<br />
<br />
it 'is invalid' do<br />
expect(due_date).to be_invalid<br />
end<br />
<br />
it 'has error on round field' do<br />
due_date.valid?<br />
expect(due_date.errors[:round]).to be_present<br />
end<br />
end<br />
<br />
context 'with nil round' do<br />
let(:due_date) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id,<br />
round: nil<br />
)<br />
end<br />
<br />
it 'is valid' do<br />
expect(due_date).to be_valid<br />
end<br />
<br />
it 'sets default round to 1' do<br />
expect(due_date.round).to eq(1)<br />
end<br />
end<br />
end<br />
end<br />
<br />
# Scope with edge cases<br />
describe '.upcoming' do<br />
it 'returns only future due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to contain_exactly(upcoming_due_date1, upcoming_due_date2)<br />
end<br />
<br />
it 'orders results by due_at ascending' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).to eq([upcoming_due_date1, upcoming_due_date2])<br />
end<br />
<br />
it 'excludes past due dates' do<br />
upcoming = DueDate.upcoming<br />
expect(upcoming).not_to include(past_due_date)<br />
end<br />
<br />
context 'when all due dates are in the past' do<br />
before do<br />
DueDate.destroy_all<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 3.days.ago,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: ok_right.id<br />
)<br />
end<br />
<br />
it 'returns empty collection' do<br />
expect(DueDate.upcoming).to be_empty<br />
end<br />
end<br />
end<br />
<br />
# Instance method with error handling<br />
describe '#copy' do<br />
let(:original) do<br />
DueDate.create(<br />
parent: assignment,<br />
due_at: 2.days.from_now,<br />
deadline_type: submission_type,<br />
submission_allowed_id: ok_right.id,<br />
review_allowed_id: late_right.id,<br />
round: 1<br />
)<br />
end<br />
<br />
let(:copied) { original.copy(assignment2.id) }<br />
<br />
it 'creates a new persisted record' do<br />
expect(copied).to be_persisted<br />
end<br />
<br />
it 'has different id from original' do<br />
expect(copied.id).not_to eq(original.id)<br />
end<br />
<br />
it 'preserves all attributes' do<br />
expect(copied.due_at).to eq(original.due_at)<br />
expect(copied.deadline_type_id).to eq(original.deadline_type_id)<br />
expect(copied.round).to eq(original.round)<br />
end<br />
<br />
context 'when copying to non-existent assignment' do<br />
it 'raises error' do<br />
expect do<br />
original.copy(99999)<br />
end.to raise_error(ActiveRecord::RecordNotFound)<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Test Metrics ===<br />
<br />
* '''DueDate model''': 60+ examples covering all methods and edge cases<br />
* '''Context depth''': 2-3 levels for complex scenarios<br />
* '''Code coverage''': 100% coverage of DueDate model methods<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Semantic Helpers''': Methods like <code>submission?</code>, <code>allows_action?</code> improve code readability<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==<br />
<br />
* Add deadline notification system using the new permission framework<br />
* Implement deadline templates for common assignment patterns<br />
* Add API endpoints for mobile app integration<br />
* Create admin dashboard for monitoring deadline compliance across courses<br />
* Add automated deadline extension workflows based on configurable rules<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Semantic Helpers''': Methods like <code>submission?</code>, <code>allows_action?</code> improve code readability<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167149
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-12-01T03:34:42Z
<p>Skim253: </p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
=== Tasks Identified ===<br />
<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy</code>) to replace class-level utilities and improve testability.<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateActions</code>) to handle permission evaluation and deadline-related operations.<br />
# Update controllers and APIs to use the new mixin-based approach for consistent permission checks and deadline queries.<br />
<br />
<br />
== Proposed Solution ==<br />
<br />
=== 1. DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT NOT NULL,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
==== DeadlineType Model Implementation ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineType < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
validates :description, presence: true<br />
<br />
has_many :due_dates, foreign_key: :deadline_type_id, dependent: :restrict_with_exception<br />
<br />
# Semantic helper methods for deadline type identification<br />
def submission?<br />
name == 'submission'<br />
end<br />
<br />
def review?<br />
name == 'review'<br />
end<br />
<br />
def teammate_review?<br />
name == 'teammate_review'<br />
end<br />
<br />
def quiz?<br />
name == 'quiz'<br />
end<br />
<br />
def team_formation?<br />
name == 'team_formation'<br />
end<br />
<br />
def signup?<br />
name == 'signup'<br />
end<br />
<br />
def drop_topic?<br />
name == 'drop_topic'<br />
end<br />
<br />
# Display methods<br />
def display_name<br />
name.humanize<br />
end<br />
<br />
def to_s<br />
display_name<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== 2. DeadlineRight Model Implementation ===<br />
<br />
==== Purpose ====<br />
<br />
The <code>DeadlineRight</code> model represents the permission level for a specific action at a given deadline.<br />
It defines three states: <code>OK</code> (action allowed), <code>Late</code> (action allowed with penalty), and <code>No</code> (action denied).<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_rights (<br />
id BIGINT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== DeadlineRight Model ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DeadlineRight < ApplicationRecord<br />
validates :name, presence: true, uniqueness: true<br />
<br />
# Permission checking methods<br />
def allows_action?<br />
%w[OK Late].include?(name)<br />
end<br />
<br />
def denies_action?<br />
name == 'No'<br />
end<br />
<br />
def allows_with_penalty?<br />
name == 'Late'<br />
end<br />
<br />
def allows_without_penalty?<br />
name == 'OK'<br />
end<br />
<br />
# Display methods<br />
def to_s<br />
name<br />
end<br />
<br />
def permission_level<br />
case name<br />
when 'No' then 0<br />
when 'Late' then 1<br />
when 'OK' then 2<br />
else -1<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 3. DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== Improved Design ====<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
belongs_to :parent, polymorphic: true<br />
belongs_to :deadline_type, foreign_key: :deadline_type_id<br />
<br />
validates :due_at, presence: true<br />
validates :deadline_type_id, presence: true<br />
validates :parent, presence: true<br />
validates :round, numericality: { greater_than: 0 }, allow_nil: true<br />
<br />
# Scopes for common queries<br />
scope :upcoming, -> { where('due_at > ?', Time.current).order(:due_at) }<br />
scope :overdue, -> { where('due_at < ?', Time.current).order(:due_at) }<br />
scope :for_round, ->(round_num) { where(round: round_num) }<br />
scope :for_deadline_type, ->(type_name) { joins(:deadline_type).where(deadline_types: { name: type_name }) }<br />
<br />
# Instance methods replace class methods<br />
def copy(to_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
new_due_date = dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
new_due_date<br />
end<br />
<br />
def set(deadline_type_id, parent_id, round)<br />
self.deadline_type_id = deadline_type_id<br />
self.parent_id = parent_id<br />
self.round = round<br />
save!<br />
end<br />
<br />
# Check if this deadline has passed<br />
def overdue?<br />
due_at < Time.current<br />
end<br />
<br />
# Check if this deadline is upcoming<br />
def upcoming?<br />
due_at > Time.current<br />
end<br />
<br />
# Get the deadline type name<br />
def deadline_type_name<br />
deadline_type&.name<br />
end<br />
<br />
# Comparison method for sorting<br />
def <=>(other)<br />
return nil unless other.is_a?(DueDate)<br />
due_at <=> other.due_at<br />
end<br />
<br />
# Class methods for collection operations<br />
class << self<br />
def sort_due_dates(due_dates)<br />
due_dates.sort_by(&:due_at)<br />
end<br />
<br />
def any_future_due_dates?(due_dates)<br />
due_dates.any?(&:upcoming?)<br />
end<br />
<br />
def copy(from_assignment_id, to_assignment_id)<br />
from_assignment = Assignment.find(from_assignment_id)<br />
to_assignment = Assignment.find(to_assignment_id)<br />
<br />
from_assignment.due_dates.each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = to_assignment<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
<br />
private<br />
<br />
before_save :set_default_round<br />
<br />
def set_default_round<br />
self.round ||= 1<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 4. Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
The new <code>DueDatePermissions</code> module integrates role-based and deadline-based checks:<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
# Permission checking methods that combine deadline-based and role-based logic<br />
#<br />
# These methods must check both:<br />
# 1. Whether the action is permitted by the current deadline (submission_allowed_id, review_allowed_id, etc.)<br />
# 2. Whether the participant has the necessary permissions (can_submit, can_review, can_take_quiz fields)<br />
<br />
# Check if submission is allowed based on both deadline and participant permissions<br />
def can_submit?(participant = nil)<br />
return false unless submission_allowed_id<br />
return false if participant && !participant.can_submit<br />
<br />
deadline_right = DeadlineRight.find_by(id: submission_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if review is allowed based on both deadline and participant permissions<br />
def can_review?(participant = nil)<br />
return false unless review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if taking a quiz is allowed based on both deadline and participant permissions<br />
def can_take_quiz?(participant = nil)<br />
return false unless quiz_allowed_id<br />
return false if participant && !participant.can_take_quiz<br />
<br />
deadline_right = DeadlineRight.find_by(id: quiz_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Check if teammate review is allowed<br />
def can_review_teammate?(participant = nil)<br />
return false unless teammate_review_allowed_id<br />
return false if participant && !participant.can_review<br />
<br />
deadline_right = DeadlineRight.find_by(id: teammate_review_allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Generic permission checker<br />
def activity_permissible?(activity)<br />
permission_field = "#{activity}_allowed_id"<br />
return false unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return false unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name&.in?(%w[OK Late])<br />
end<br />
<br />
# Get permission status for an action (OK, Late, No)<br />
def permission_status_for(action)<br />
permission_field = "#{action}_allowed_id"<br />
return 'No' unless respond_to?(permission_field)<br />
<br />
allowed_id = public_send(permission_field)<br />
return 'No' unless allowed_id<br />
<br />
deadline_right = DeadlineRight.find_by(id: allowed_id)<br />
deadline_right&.name || 'No'<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in the <code>DueDate</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 5. DueDateActions Mixin ===<br />
<br />
The <code>DueDateActions</code> module provides deadline-related operations for models that have due dates (Assignment, SignUpTopic).<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateActions<br />
# Generic activity permission checker that determines if an activity is permissible<br />
# based on the current deadline state for this parent object<br />
def activity_permissible?(activity)<br />
current_deadline = next_due_date()<br />
return false unless current_deadline<br />
<br />
current_deadline.activity_permissible?(activity)<br />
end<br />
<br />
# Syntactic sugar methods for common activities<br />
def submission_permissible?<br />
activity_permissible?(:submission)<br />
end<br />
<br />
def review_permissible?<br />
activity_permissible?(:review)<br />
end<br />
<br />
def teammate_review_permissible?<br />
activity_permissible?(:teammate_review)<br />
end<br />
<br />
def quiz_permissible?<br />
activity_permissible?(:quiz)<br />
end<br />
<br />
def team_formation_permissible?<br />
activity_permissible?(:team_formation)<br />
end<br />
<br />
def signup_permissible?<br />
activity_permissible?(:signup)<br />
end<br />
<br />
def drop_topic_permissible?<br />
activity_permissible?(:drop_topic)<br />
end<br />
<br />
# Get the next due date for this assignment<br />
def next_due_date(topic_id = nil)<br />
# If a topic is specified and this assignment has topic-specific deadlines,<br />
# look for topic due dates first<br />
if topic_id && has_topic_specific_deadlines?<br />
topic_deadline = due_dates.where(parent_id: topic_id, parent_type: 'SignUpTopic')<br />
.upcoming<br />
.first<br />
return topic_deadline if topic_deadline<br />
end<br />
<br />
# Fall back to assignment-level due dates<br />
due_dates.upcoming.first<br />
end<br />
<br />
# Get the current stage name for display purposes<br />
def current_stage<br />
deadline = next_due_date()<br />
return 'finished' unless deadline<br />
<br />
deadline.deadline_type&.name || 'unknown'<br />
end<br />
<br />
# Check if assignment has topic-specific deadlines<br />
def has_topic_specific_deadlines?<br />
staggered_deadline || due_dates.where(parent_type: 'SignUpTopic').exists?<br />
end<br />
<br />
# Copy due dates to a new parent object<br />
def copy_due_dates_to(new_parent)<br />
due_dates.find_each do |due_date|<br />
new_due_date = due_date.dup<br />
new_due_date.parent = new_parent<br />
new_due_date.save!<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This module is included in <code>Assignment</code> and <code>SignUpTopic</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
<br />
class SignUpTopic < ApplicationRecord<br />
include DueDateActions<br />
# ...<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 6. Controller and API Updates ===<br />
<br />
Controllers can now use the new unified mixins for permission checks and deadline queries.<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDatesController < ApplicationController<br />
def can_perform_action<br />
assignment = Assignment.find(params[:assignment_id])<br />
participant = current_user.participant_for(assignment)<br />
current_due_date = assignment.next_due_date(params[:topic_id])<br />
<br />
action = params[:action_type].to_sym<br />
allowed = case action<br />
when :submit then current_due_date&.can_submit?(participant)<br />
when :review then current_due_date&.can_review?(participant)<br />
when :quiz then current_due_date&.can_take_quiz?(participant)<br />
else false<br />
end<br />
<br />
render json: { allowed: allowed, current_stage: assignment.current_stage }<br />
end<br />
<br />
def upcoming_deadlines<br />
assignment = Assignment.find(params[:assignment_id])<br />
deadlines = assignment.due_dates.upcoming.limit(5)<br />
render json: deadlines<br />
end<br />
<br />
def current_stage<br />
assignment = Assignment.find(params[:assignment_id])<br />
render json: { <br />
stage: assignment.current_stage,<br />
next_deadline: assignment.next_due_date<br />
}<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== New Endpoints ====<br />
* <code>GET /assignments/:id/due_dates/permissions?action_type=submit</code> — Check if user can perform an action<br />
* <code>GET /assignments/:id/due_dates/upcoming</code> — Get upcoming deadlines <br />
* <code>GET /assignments/:id/due_dates/current_stage</code> — Get current stage and next deadline<br />
<br />
<br />
== Testing Plan ==<br />
<br />
The current test suite already includes RSpec tests for ''Assignment'' and ''DueDate'' models.<br />
These tests verify whether deadlines allow actions such as submission, review, or quiz based on ''DeadlineRight''.<br />
However, they only validate time-based permissions, not user role constraints.<br />
<br />
=== Current Coverage ===<br />
<br />
* '''DueDate validations''' ensure required fields (parent, due_at, deadline_type_id) are present<br />
* '''DueDate scopes''' test upcoming, overdue, for_round, and for_deadline_type queries<br />
* '''DueDate instance methods''' verify overdue?, upcoming?, set, copy, and comparison operations<br />
* '''DueDate class methods''' test sort_due_dates, any_future_due_dates?, and copy operations<br />
* '''DueDate callbacks''' verify default round setting behavior<br />
<br />
No existing tests consider ''Participant'' role flags (''can_submit'', ''can_review'', ''can_take_quiz'').<br />
<br />
=== Planned Updates ===<br />
<br />
* Add tests for ''DueDatePermissions'' module methods: ''can_submit?'', ''can_review?'', and ''can_take_quiz?'' with participant parameters<br />
* Add tests for ''DueDateActions'' module methods in Assignment context<br />
* Test integration of role-based and time-based logic through unified permission checking<br />
* Verify backward compatibility with existing ''Assignment'' tests<br />
<br />
=== Example Test Cases ===<br />
<br />
<syntaxhighlight lang="ruby"><br />
describe DueDate, '#can_submit?' do<br />
let(:due_date) { create(:due_date, submission_allowed_id: ok_right.id) }<br />
let(:participant) { create(:participant, can_submit: true) }<br />
<br />
it 'returns true when both deadline and participant allow submission' do<br />
expect(due_date.can_submit?(participant)).to be true<br />
end<br />
<br />
it 'returns false when participant cannot submit' do<br />
participant.can_submit = false<br />
expect(due_date.can_submit?(participant)).to be false<br />
end<br />
<br />
it 'returns false when deadline does not allow submission' do<br />
due_date.submission_allowed_id = no_right.id<br />
expect(due_date.can_submit?(participant)).to be false<br />
end<br />
end<br />
<br />
describe Assignment, '#activity_permissible?' do<br />
let(:assignment) { create(:assignment) }<br />
let(:due_date) { create(:due_date, parent: assignment, submission_allowed_id: ok_right.id) }<br />
<br />
it 'returns true when current deadline allows the activity' do<br />
expect(assignment.activity_permissible?(:submission)).to be true<br />
end<br />
<br />
it 'returns false when no upcoming deadline exists' do<br />
due_date.update(due_at: 1.day.ago)<br />
expect(assignment.activity_permissible?(:submission)).to be false<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Expected Outcome ===<br />
<br />
* Both user roles and deadlines influence action permissions<br />
* Permission checks are consistent across the application<br />
* All existing tests continue to pass<br />
* New tests verify the integrated permission system<br />
<br />
<br />
== Implementation Summary ==<br />
<br />
=== Models Created/Modified ===<br />
<br />
* '''DeadlineType''' - Canonical deadline type definitions with semantic helper methods<br />
* '''DeadlineRight''' - Permission state model (OK/Late/No) with comparison methods<br />
* '''DueDate''' - Refactored with instance methods, scopes, and permission checking<br />
* '''TopicDueDate''' - STI subclass for topic-specific deadlines<br />
* '''Assignment''' - Includes DueDateActions mixin<br />
* '''SignUpTopic''' - Includes DueDateActions mixin<br />
<br />
=== Modules Created ===<br />
<br />
* '''DueDatePermissions''' - Permission checking combining deadline and role constraints<br />
* '''DueDateActions''' - Deadline-related operations for parent models (Assignment, SignUpTopic)<br />
<br />
=== Key Improvements ===<br />
<br />
# '''Separation of Concerns''': Permission logic separated into dedicated modules<br />
# '''Instance Methods''': Replaced class methods with testable instance methods<br />
# '''Semantic Helpers''': Methods like <code>submission?</code>, <code>allows_action?</code> improve code readability<br />
# '''Polymorphic Design''': Single DueDate model serves both Assignment and SignUpTopic<br />
# '''Unified Permissions''': Role-based and time-based checks combined in one interface<br />
# '''Data Integrity''': Removed duplicate deadline types, enforced foreign key constraints<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167089
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-11-11T01:11:32Z
<p>Skim253: </p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
====Admin's View====<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
====Student's View====<br />
[[File:Student-assignments.png|600px]]<br />
* Students can view the due date information under <code>Current State</code> and <code>Stage Deadline</code>. <br />
<br />
* The actions available to students are determined by the current DueDate status.<br />
<br />
[[File:Student-duedate-not-over.png|600px]]<br />
* For example, during the submission period, students can access the <code>Submit a hyperlink</code> and <code>Submit a file</code> sections.<br />
<br />
[[File:Student-duedate-over.png|600px]]<br />
* Once the due date has passed, students cannot submit either a hyperlink or a file.<br />
<br />
<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
=== Tasks Identified ===<br />
<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy_to</code>) to replace class-level utilities and improve testability.<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateQueries</code>) to handle permission evaluation and query operations.<br />
# Update controllers and APIs to use the new mixin-based approach for consistent permission checks and deadline queries.<br />
<br />
<br />
== Proposed Solution ==<br />
<br />
=== 1. DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id INT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines (NEW) <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
<br />
=== 2. DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
To address this:<br />
* Replace class methods with instance-level methods.<br />
* Move sorting, copying, and query logic to mixins.<br />
* Introduce mixins such as <code>DueDatePermissions</code> for permission-related checks.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Improved design<br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
def copy_to(new_assignment)<br />
dup.tap { |d| d.parent_id = new_assignment.id }.save<br />
end<br />
<br />
def next_due_date<br />
DueDate.where('due_at > ?', Time.zone.now).order(:due_at).first<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 3. Add Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
Integrate role-based and deadline-based checks into the <code>DueDate</code> model (or a dedicated mixin):<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
def can_submit?<br />
right = DeadlineRight.find(submission_allowed_id)<br />
right.name.in?(%w[OK Late])<br />
end<br />
<br />
def can_review?<br />
right = DeadlineRight.find(review_allowed_id)<br />
right.name.in?(%w[OK Late])<br />
end<br />
<br />
def can_take_quiz?<br />
right = DeadlineRight.find(quiz_allowed_id)<br />
right.name.in?(%w[OK Late])<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
Then unify both layers via <code>Participant</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Participant < ApplicationRecord<br />
def allowed_to?(action, assignment, topic_id = nil)<br />
due_date = assignment.find_current_stage(topic_id)<br />
return false if due_date.nil?<br />
<br />
case action<br />
when :submit then can_submit && due_date.can_submit?<br />
when :review then can_review && due_date.can_review?<br />
when :quiz then can_take_quiz && due_date.can_take_quiz?<br />
else false<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This ensures that permission logic respects both the participant’s role and the current deadline phase.<br />
<br />
<br />
=== 4. Permission and Query Mixins ===<br />
<br />
Encapsulate permission and query logic in reusable mixins instead of separate service classes.<br />
This approach keeps logic close to the models and removes the need for dedicated service objects, improving maintainability and cohesion.<br />
<br />
==== DueDatePermissions Mixin ====<br />
Permission checks that combine user role and deadline phase.<br />
It is included in the Participant model for unified access control.<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
def can_submit?(user, assignment)<br />
user.participant.allowed_to?(:submit, assignment)<br />
end<br />
<br />
def can_review?(user, assignment)<br />
user.participant.allowed_to?(:review, assignment)<br />
end<br />
<br />
def can_form_teams?(user, assignment)<br />
user.participant.allowed_to?(:team_formation, assignment)<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
Example integration:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Participant < ApplicationRecord<br />
include DueDatePermissions<br />
end<br />
</syntaxhighlight><br />
<br />
==== DueDateQueries Mixin ====<br />
Reusable query methods for upcoming and overdue deadlines.<br />
It is included in the Assignment model to simplify deadline lookups.<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateQueries<br />
def upcoming_deadlines(limit: 5)<br />
due_dates<br />
.where('due_at > ?', Time.zone.now)<br />
.order(:due_at)<br />
.limit(limit)<br />
end<br />
<br />
def overdue_deadlines<br />
due_dates<br />
.where('due_at < ?', Time.zone.now)<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
Example integration:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateQueries<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 5. Controller and API Updates ===<br />
<br />
Controllers can now use the new unified mixins (<code>DueDatePermissions</code>, <code>DueDateQueries</code>) <br />
for permission checks and deadline queries.<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDatesController < ApplicationController<br />
def can_perform_action<br />
action = params[:action_type].to_sym<br />
allowed = current_user.participant.public_send("can_#{action}?", current_user, @assignment)<br />
render json: { allowed: allowed }<br />
end<br />
<br />
def upcoming_deadlines<br />
deadlines = @assignment.upcoming_deadlines<br />
render json: deadlines<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== New Endpoints ====<br />
* <code>GET /assignments/:id/due_dates/permissions</code> — Check user permissions for various actions <br />
* <code>GET /assignments/:id/due_dates/upcoming</code> — Get upcoming deadlines <br />
* <code>GET /assignments/:id/due_dates/current/:action_type</code> — Get current deadline for a specific action <br />
<br />
<br />
== Testing Plan ==<br />
<br />
The current test suite already includes RSpec tests for ''Assignment'' and ''DueDate'' models.<br />
These tests verify whether deadlines allow actions such as submission, review, or quiz based on ''DeadlineRight''.<br />
However, they only validate time-based permissions, not user role constraints.<br />
<br />
=== Current Coverage ===<br />
<br />
'''Assignment#check_condition''' ensures correct evaluation of ''DeadlineRight'' values (''OK'', ''Late'', ''No'').<br />
<br />
'''submission_allowed''', '''quiz_allowed''', and '''can_review''' are tested for deadline behavior.<br />
<br />
No existing tests consider ''Participant'' role flags (''can_submit'', ''can_review'', ''can_take_quiz'').<br />
<br />
=== Planned Updates ===<br />
<br />
Add tests for new ''DueDate'' instance methods: ''can_submit?'', ''can_review?'', and ''can_take_quiz?''.<br />
<br />
Integrate role-based and time-based logic under a unified interface in ''Participant#allowed_to?''.<br />
<br />
Additionally, verify that ''DueDatePermissions'' and ''DueDateQueries'' mixins return consistent results compared to the previous service-based approach.<br />
<br />
Ensure backward compatibility with existing ''Assignment'' tests.<br />
<br />
=== Example Case ===<br />
<syntaxhighlight lang="ruby"><br />
describe Participant, '#allowed_to?' do<br />
it 'returns false when role allows submission but deadline is closed' do<br />
allow(assignment).to receive(:find_current_stage).and_return(due_date)<br />
allow(DeadlineRight).to receive(:find).and_return(double(name: 'No'))<br />
expect(participant.allowed_to?(:submit, assignment)).to be false<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Expected Outcome ===<br />
<br />
Both user roles and deadlines influence action permissions.<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=File:Student-duedate-not-over.png&diff=167088
File:Student-duedate-not-over.png
2025-11-11T01:06:09Z
<p>Skim253: </p>
<hr />
<div></div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=File:Student-duedate-over.png&diff=167087
File:Student-duedate-over.png
2025-11-11T01:05:56Z
<p>Skim253: </p>
<hr />
<div></div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=File:Student-assignments.png&diff=167086
File:Student-assignments.png
2025-11-11T01:05:46Z
<p>Skim253: </p>
<hr />
<div></div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167081
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-11-10T23:42:36Z
<p>Skim253: </p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Current Behavior ===<br />
<br />
[[File:Duedates.png|600px]]<br />
<br />
* When editing an assignment, due dates can be modified under the Due Dates tab.<br />
* Each row contains the following columns: <code>Date & Time</code>, <code>Use Date Updater</code>, <code>Submission Allowed</code>, <code>Review Allowed</code>, <code>Teammate Review Allowed</code>, <code>Meta-Review Allowed</code>, and <code>Reminder</code>.<br />
<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
<br />
* In the Assignments table, the ''DueDate'' of each assignment is displayed as Current Stage and Stage Deadline.<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
=== Tasks Identified ===<br />
<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy_to</code>) to replace class-level utilities and improve testability.<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateQueries</code>) to handle permission evaluation and query operations.<br />
# Update controllers and APIs to use the new mixin-based approach for consistent permission checks and deadline queries.<br />
<br />
<br />
== Proposed Solution ==<br />
<br />
=== 1. DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id INT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines (NEW) <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
<br />
=== 2. DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
To address this:<br />
* Replace class methods with instance-level methods.<br />
* Move sorting, copying, and query logic to mixins.<br />
* Introduce mixins such as <code>DueDatePermissions</code> for permission-related checks.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Improved design<br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
def copy_to(new_assignment)<br />
dup.tap { |d| d.parent_id = new_assignment.id }.save<br />
end<br />
<br />
def next_due_date<br />
DueDate.where('due_at > ?', Time.zone.now).order(:due_at).first<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 3. Add Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
Integrate role-based and deadline-based checks into the <code>DueDate</code> model (or a dedicated mixin):<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
def can_submit?<br />
right = DeadlineRight.find(submission_allowed_id)<br />
right.name.in?(%w[OK Late])<br />
end<br />
<br />
def can_review?<br />
right = DeadlineRight.find(review_allowed_id)<br />
right.name.in?(%w[OK Late])<br />
end<br />
<br />
def can_take_quiz?<br />
right = DeadlineRight.find(quiz_allowed_id)<br />
right.name.in?(%w[OK Late])<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
Then unify both layers via <code>Participant</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Participant < ApplicationRecord<br />
def allowed_to?(action, assignment, topic_id = nil)<br />
due_date = assignment.find_current_stage(topic_id)<br />
return false if due_date.nil?<br />
<br />
case action<br />
when :submit then can_submit && due_date.can_submit?<br />
when :review then can_review && due_date.can_review?<br />
when :quiz then can_take_quiz && due_date.can_take_quiz?<br />
else false<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This ensures that permission logic respects both the participant’s role and the current deadline phase.<br />
<br />
<br />
=== 4. Permission and Query Mixins ===<br />
<br />
Encapsulate permission and query logic in reusable mixins instead of separate service classes.<br />
This approach keeps logic close to the models and removes the need for dedicated service objects, improving maintainability and cohesion.<br />
<br />
==== DueDatePermissions Mixin ====<br />
Permission checks that combine user role and deadline phase.<br />
It is included in the Participant model for unified access control.<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
def can_submit?(user, assignment)<br />
user.participant.allowed_to?(:submit, assignment)<br />
end<br />
<br />
def can_review?(user, assignment)<br />
user.participant.allowed_to?(:review, assignment)<br />
end<br />
<br />
def can_form_teams?(user, assignment)<br />
user.participant.allowed_to?(:team_formation, assignment)<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
Example integration:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Participant < ApplicationRecord<br />
include DueDatePermissions<br />
end<br />
</syntaxhighlight><br />
<br />
==== DueDateQueries Mixin ====<br />
Reusable query methods for upcoming and overdue deadlines.<br />
It is included in the Assignment model to simplify deadline lookups.<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateQueries<br />
def upcoming_deadlines(limit: 5)<br />
due_dates<br />
.where('due_at > ?', Time.zone.now)<br />
.order(:due_at)<br />
.limit(limit)<br />
end<br />
<br />
def overdue_deadlines<br />
due_dates<br />
.where('due_at < ?', Time.zone.now)<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
Example integration:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateQueries<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 5. Controller and API Updates ===<br />
<br />
Controllers can now use the new unified mixins (<code>DueDatePermissions</code>, <code>DueDateQueries</code>) <br />
for permission checks and deadline queries.<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDatesController < ApplicationController<br />
def can_perform_action<br />
action = params[:action_type].to_sym<br />
allowed = current_user.participant.public_send("can_#{action}?", current_user, @assignment)<br />
render json: { allowed: allowed }<br />
end<br />
<br />
def upcoming_deadlines<br />
deadlines = @assignment.upcoming_deadlines<br />
render json: deadlines<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== New Endpoints ====<br />
* <code>GET /assignments/:id/due_dates/permissions</code> — Check user permissions for various actions <br />
* <code>GET /assignments/:id/due_dates/upcoming</code> — Get upcoming deadlines <br />
* <code>GET /assignments/:id/due_dates/current/:action_type</code> — Get current deadline for a specific action <br />
<br />
<br />
== Testing Plan ==<br />
<br />
The current test suite already includes RSpec tests for ''Assignment'' and ''DueDate'' models.<br />
These tests verify whether deadlines allow actions such as submission, review, or quiz based on ''DeadlineRight''.<br />
However, they only validate time-based permissions, not user role constraints.<br />
<br />
=== Current Coverage ===<br />
<br />
'''Assignment#check_condition''' ensures correct evaluation of ''DeadlineRight'' values (''OK'', ''Late'', ''No'').<br />
<br />
'''submission_allowed''', '''quiz_allowed''', and '''can_review''' are tested for deadline behavior.<br />
<br />
No existing tests consider ''Participant'' role flags (''can_submit'', ''can_review'', ''can_take_quiz'').<br />
<br />
=== Planned Updates ===<br />
<br />
Add tests for new ''DueDate'' instance methods: ''can_submit?'', ''can_review?'', and ''can_take_quiz?''.<br />
<br />
Integrate role-based and time-based logic under a unified interface in ''Participant#allowed_to?''.<br />
<br />
Additionally, verify that ''DueDatePermissions'' and ''DueDateQueries'' mixins return consistent results compared to the previous service-based approach.<br />
<br />
Ensure backward compatibility with existing ''Assignment'' tests.<br />
<br />
=== Example Case ===<br />
<syntaxhighlight lang="ruby"><br />
describe Participant, '#allowed_to?' do<br />
it 'returns false when role allows submission but deadline is closed' do<br />
allow(assignment).to receive(:find_current_stage).and_return(due_date)<br />
allow(DeadlineRight).to receive(:find).and_return(double(name: 'No'))<br />
expect(participant.allowed_to?(:submit, assignment)).to be false<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Expected Outcome ===<br />
<br />
Both user roles and deadlines influence action permissions.<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2566._Finish_DueDates&diff=167076
CSC/ECE 517 Fall 2025 - E2566. Finish DueDates
2025-11-10T23:36:21Z
<p>Skim253: </p>
<hr />
<div>== Introduction ==<br />
<br />
=== Background ===<br />
<br />
This project aims to complete the implementation of the DueDate system in Expertiza. The current implementation consists mostly of class methods and lacks proper definition of different deadline types and permission checking functionality. This redesign will create a more robust, readable, and maintainable due date system.<br />
<br />
=== Existing Components ===<br />
[[File:Duedates.png|600px]]<br />
[[File:Assignments-CurrentStage.png|600px]]<br />
* <code>DueDate</code> model with polymorphic parent association (Assignment/SignUpTopic)<br />
* <code>AssignmentDueDate</code> and <code>TopicDueDate</code> subclasses<br />
* Basic CRUD operations (within <code>Assignment</code> and <code>AssignmentForm</code>) and sorting functionality (<code>deadline_sort</code>)<br />
* Database schema with <code>deadline_type_id</code> field<br />
<br />
=== Motivation ===<br />
Currently, there are some glaring issues with how due_dates was created in the first place, including redundancy and lack of modularity.<br />
<br />
# No dedicated <code>DeadlineType</code> model to define different kinds of deadlines. The existing <code>DeadlineType</code> class only serves as an association for <code>AssignmentDueDate</code> and <code>TopicDueDate</code> models, and is never referenced in the current <code>DueDate</code> implementation.<br />
# Overuse of class methods making the code difficult to maintain.<br />
# Missing permission checking logic for user actions.<br />
# Incomplete deadline type definitions — <code>teammate_review</code>, <code>quiz</code> need to be added.<br />
# Duplicate <code>team_formation</code> entries in <code>deadline_types</code> table, which may lead to potential bugs.<br />
# No clear separation of concerns — data persistence, business logic, and permission logic are mixed in a single model.<br />
<br />
=== Tasks Identified ===<br />
<br />
# Redesign the <code>DeadlineType</code> model to act as the single source of truth for all deadline categories, replacing hard-coded IDs and redundant entries.<br />
# Refactor the <code>DueDate</code> model to separate persistence, business logic, and permission logic into distinct layers.<br />
# Introduce instance-level methods (e.g., <code>next_due_date</code>, <code>copy_to</code>) to replace class-level utilities and improve testability.<br />
# Integrate role-based and time-based permission checks within <code>DueDate</code> and <code>Participant</code> to ensure consistent access control.<br />
# Add missing deadline types (<code>teammate_review</code>, <code>quiz</code>) and remove duplicate <code>team_formation</code> entries for data integrity.<br />
# Implement reusable mixins (e.g., <code>DueDatePermissions</code>, <code>DueDateQueries</code>) to handle permission evaluation and query operations.<br />
# Update controllers and APIs to use the new mixin-based approach for consistent permission checks and deadline queries.<br />
<br />
<br />
== Proposed Solution ==<br />
<br />
=== 1. DeadlineType Model Implementation ===<br />
<br />
==== Current Problems ====<br />
<br />
Although the current codebase includes a <code>DeadlineType</code> model, it only serves as a passive lookup table for associations with <code>AssignmentDueDate</code> and <code>TopicDueDate</code>. <br />
In practice, most parts of the system still rely on hard-coded numeric IDs or manual lookups such as:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Example of current usage<br />
deadline_type_id = DeadlineType.find_by(name: 'review').id<br />
if due_date.deadline_type_id == deadline_type_id<br />
# Perform review-related logic<br />
end<br />
</syntaxhighlight><br />
<br />
Instead of using the model as an active domain object, <code>DueDate</code> directly compares IDs or string literals. <br />
This leads to several structural issues:<br />
<br />
* Inconsistent references (some use IDs, others strings)<br />
* Tight coupling between <code>DueDate</code> and <code>deadline_type_id</code><br />
* Lack of helper semantics (e.g., <code>is_review?</code>, <code>is_submission?</code>)<br />
* Data duplication and integrity risks (two <code>team_formation</code> rows)<br />
<br />
The redesigned <code>DeadlineType</code> will serve as a source of truth, defining all valid deadline types and providing meaningful interfaces.<br />
<br />
==== Database Schema ====<br />
<syntaxhighlight lang="sql"><br />
CREATE TABLE deadline_types (<br />
id INT PRIMARY KEY,<br />
name VARCHAR(255) NOT NULL UNIQUE,<br />
description TEXT,<br />
created_at TIMESTAMP,<br />
updated_at TIMESTAMP<br />
);<br />
</syntaxhighlight><br />
<br />
==== Deadline Type Definitions ====<br />
* <code>1</code>: submission - Student work submission deadlines <br />
* <code>2</code>: review - Peer review deadlines <br />
* <code>3</code>: teammate_review - Team member evaluation deadlines (NEW) <br />
* <code>5</code>: metareview - Meta-review deadlines (kept for backward compatibility) <br />
* <code>6</code>: drop_topic - Topic drop deadlines <br />
* <code>7</code>: signup - Course/assignment signup deadlines <br />
* <code>8</code>: team_formation - Team formation deadlines (clean up duplicate ID 10) <br />
* <code>11</code>: quiz - Quiz completion deadlines<br />
<br />
<br />
=== 2. DueDate Model Refactoring ===<br />
<br />
==== Current Problems ====<br />
<br />
The <code>DueDate</code> model currently mixes persistence logic, deadline calculation, and permission checking, violating SRP. <br />
Most of its logic is implemented as class methods, which makes testing and extension difficult.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Current design<br />
def self.copy(old_assignment_id, new_assignment_id)<br />
duedates = where(parent_id: old_assignment_id)<br />
duedates.each do |orig_due_date|<br />
new_due_date = orig_due_date.dup<br />
new_due_date.parent_id = new_assignment_id<br />
new_due_date.save<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
To address this:<br />
* Replace class methods with instance-level methods.<br />
* Move sorting, copying, and query logic to mixins.<br />
* Introduce mixins such as <code>DueDatePermissions</code> for permission-related checks.<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Improved design<br />
class DueDate < ApplicationRecord<br />
include DueDatePermissions<br />
<br />
def copy_to(new_assignment)<br />
dup.tap { |d| d.parent_id = new_assignment.id }.save<br />
end<br />
<br />
def next_due_date<br />
DueDate.where('due_at > ?', Time.zone.now).order(:due_at).first<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 3. Add Permission-Checking Methods ===<br />
<br />
==== Current Problems ====<br />
<br />
Currently, permission checks depend only on user roles and ignore the actual deadline. <br />
For example:<br />
<br />
<syntaxhighlight lang="ruby"><br />
# Role-based permissions (participant_helpers.rb)<br />
def participant_permissions(authorization)<br />
case authorization<br />
when 'reader' then { can_submit: false, can_review: true, can_take_quiz: true }<br />
when 'reviewer' then { can_submit: false, can_review: true, can_take_quiz: false }<br />
when 'submitter' then { can_submit: true, can_review: false, can_take_quiz: false }<br />
else { can_submit: true, can_review: true, can_take_quiz: true }<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
And deadline-based checks exist separately in the <code>Assignment</code> model:<br />
<br />
<syntaxhighlight lang="ruby"><br />
def submission_allowed(topic_id = nil)<br />
check_condition('submission_allowed_id', topic_id)<br />
end<br />
<br />
def can_review(topic_id = nil)<br />
check_condition('review_allowed_id', topic_id)<br />
end<br />
</syntaxhighlight><br />
<br />
These two layers (role-based and time-based) never interact, leading to inconsistencies (e.g., a user with <code>can_submit=true</code> after deadline).<br />
<br />
==== Proposed Changes ====<br />
<br />
Integrate role-based and deadline-based checks into the <code>DueDate</code> model (or a dedicated mixin):<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDate < ApplicationRecord<br />
def can_submit?<br />
right = DeadlineRight.find(submission_allowed_id)<br />
right.name.in?(%w[OK Late])<br />
end<br />
<br />
def can_review?<br />
right = DeadlineRight.find(review_allowed_id)<br />
right.name.in?(%w[OK Late])<br />
end<br />
<br />
def can_take_quiz?<br />
right = DeadlineRight.find(quiz_allowed_id)<br />
right.name.in?(%w[OK Late])<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
Then unify both layers via <code>Participant</code>:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Participant < ApplicationRecord<br />
def allowed_to?(action, assignment, topic_id = nil)<br />
due_date = assignment.find_current_stage(topic_id)<br />
return false if due_date.nil?<br />
<br />
case action<br />
when :submit then can_submit && due_date.can_submit?<br />
when :review then can_review && due_date.can_review?<br />
when :quiz then can_take_quiz && due_date.can_take_quiz?<br />
else false<br />
end<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
This ensures that permission logic respects both the participant’s role and the current deadline phase.<br />
<br />
<br />
=== 4. Permission and Query Mixins ===<br />
<br />
Encapsulate permission and query logic in reusable mixins instead of separate service classes.<br />
This approach keeps logic close to the models and removes the need for dedicated service objects, improving maintainability and cohesion.<br />
<br />
==== DueDatePermissions Mixin ====<br />
Permission checks that combine user role and deadline phase.<br />
It is included in the Participant model for unified access control.<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDatePermissions<br />
def can_submit?(user, assignment)<br />
user.participant.allowed_to?(:submit, assignment)<br />
end<br />
<br />
def can_review?(user, assignment)<br />
user.participant.allowed_to?(:review, assignment)<br />
end<br />
<br />
def can_form_teams?(user, assignment)<br />
user.participant.allowed_to?(:team_formation, assignment)<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
Example integration:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Participant < ApplicationRecord<br />
include DueDatePermissions<br />
end<br />
</syntaxhighlight><br />
<br />
==== DueDateQueries Mixin ====<br />
Reusable query methods for upcoming and overdue deadlines.<br />
It is included in the Assignment model to simplify deadline lookups.<br />
<br />
<syntaxhighlight lang="ruby"><br />
module DueDateQueries<br />
def upcoming_deadlines(limit: 5)<br />
due_dates<br />
.where('due_at > ?', Time.zone.now)<br />
.order(:due_at)<br />
.limit(limit)<br />
end<br />
<br />
def overdue_deadlines<br />
due_dates<br />
.where('due_at < ?', Time.zone.now)<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
Example integration:<br />
<br />
<syntaxhighlight lang="ruby"><br />
class Assignment < ApplicationRecord<br />
include DueDateQueries<br />
end<br />
</syntaxhighlight><br />
<br />
<br />
=== 5. Controller and API Updates ===<br />
<br />
Controllers can now use the new unified mixins (<code>DueDatePermissions</code>, <code>DueDateQueries</code>) <br />
for permission checks and deadline queries.<br />
<br />
<syntaxhighlight lang="ruby"><br />
class DueDatesController < ApplicationController<br />
def can_perform_action<br />
action = params[:action_type].to_sym<br />
allowed = current_user.participant.public_send("can_#{action}?", current_user, @assignment)<br />
render json: { allowed: allowed }<br />
end<br />
<br />
def upcoming_deadlines<br />
deadlines = @assignment.upcoming_deadlines<br />
render json: deadlines<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
==== New Endpoints ====<br />
* <code>GET /assignments/:id/due_dates/permissions</code> — Check user permissions for various actions <br />
* <code>GET /assignments/:id/due_dates/upcoming</code> — Get upcoming deadlines <br />
* <code>GET /assignments/:id/due_dates/current/:action_type</code> — Get current deadline for a specific action <br />
<br />
<br />
== Testing Plan ==<br />
<br />
The current test suite already includes RSpec tests for ''Assignment'' and ''DueDate'' models.<br />
These tests verify whether deadlines allow actions such as submission, review, or quiz based on ''DeadlineRight''.<br />
However, they only validate time-based permissions, not user role constraints.<br />
<br />
=== Current Coverage ===<br />
<br />
'''Assignment#check_condition''' ensures correct evaluation of ''DeadlineRight'' values (''OK'', ''Late'', ''No'').<br />
<br />
'''submission_allowed''', '''quiz_allowed''', and '''can_review''' are tested for deadline behavior.<br />
<br />
No existing tests consider ''Participant'' role flags (''can_submit'', ''can_review'', ''can_take_quiz'').<br />
<br />
=== Planned Updates ===<br />
<br />
Add tests for new ''DueDate'' instance methods: ''can_submit?'', ''can_review?'', and ''can_take_quiz?''.<br />
<br />
Integrate role-based and time-based logic under a unified interface in ''Participant#allowed_to?''.<br />
<br />
Additionally, verify that ''DueDatePermissions'' and ''DueDateQueries'' mixins return consistent results compared to the previous service-based approach.<br />
<br />
Ensure backward compatibility with existing ''Assignment'' tests.<br />
<br />
=== Example Case ===<br />
<syntaxhighlight lang="ruby"><br />
describe Participant, '#allowed_to?' do<br />
it 'returns false when role allows submission but deadline is closed' do<br />
allow(assignment).to receive(:find_current_stage).and_return(due_date)<br />
allow(DeadlineRight).to receive(:find).and_return(double(name: 'No'))<br />
expect(participant.allowed_to?(:submit, assignment)).to be false<br />
end<br />
end<br />
</syntaxhighlight><br />
<br />
=== Expected Outcome ===<br />
<br />
Both user roles and deadlines influence action permissions.<br />
<br />
<br />
== Demo ==<br />
=== Demo Video ===<br />
<br />
=== Demo Link ===<br />
<br />
<br />
== Future Work ==</div>
Skim253
https://wiki.expertiza.ncsu.edu/index.php?title=File:Assignments-CurrentStage.png&diff=167075
File:Assignments-CurrentStage.png
2025-11-10T23:35:55Z
<p>Skim253: </p>
<hr />
<div></div>
Skim253