CSC/ECE 517 Spring 2026 - E2601. Reimplement student quizzes

From Expertiza_Wiki
Revision as of 01:21, 31 March 2026 by Avkumar2 (talk | contribs)
Jump to navigation Jump to search

E2601: Reimplementation of the Student Quiz System

E2601: Reimplementation of the Student Quiz System is a graduate-level project conducted as part of the CSC/ECE 517 course at North Carolina State University in Spring 2026. The project focuses on modernizing the quiz subsystem within the Expertiza peer review platform, ensuring correct sequencing of tasks in multi-step assignment workflows.

Background

Expertiza is an open-source platform developed at North Carolina State University that facilitates structured peer reviews, team-based assignments, and multi-stage workflows including submissions, reviews, quizzes, and feedback.<ref>https://github.com/expertiza/expertiza </ref> In Expertiza, each assignment is organized as a workflow, where students must complete tasks in a prescribed order. Accurate task sequencing is essential to maintain the integrity of these workflows, particularly for quiz tasks, which may depend on prior completion of submission or review stages.

The platform is being reimplemented to separate the backend (Rails API) and frontend (React SPA), emphasizing modularity, test coverage, and adherence to RESTful principles.<ref>https://guides.rubyonrails.org </ref>

Objectives

The project addressed three primary challenges:

Implementing reliable task sequencing logic for student workflows. Developing a student-facing API for task visibility and management. Ensuring secure creation and updating of quiz responses with authentication and prerequisite checks.

System Architecture

The reimplementation separates responsibilities into three layers: task ordering, student task API, and response management API.

Task Ordering Layer

The TaskOrdering module encapsulates all logic related to task sequencing and eligibility. It is independent of controllers and HTTP requests.

Key components include:

BaseTask: Abstract interface for all task types. ReviewTask: Represents review tasks; completion depends on submission status. QuizTask: Represents quiz tasks and determines completion state. TaskFactory: Maps response maps to task objects. TaskQueue: Orchestrates ordered tasks and provides eligibility queries.

The module determines whether a task belongs to a student, verifies completion of prior tasks, and identifies the next actionable task.

Student Task API

The student task API exposes task information via five endpoints:

/student_tasks/list – Lists all tasks for a student. /student_tasks/view – Provides detailed task information. /student_tasks/queue – Returns the ordered task queue for an assignment. /student_tasks/next_task – Retrieves the next incomplete task. /student_tasks/start_task – Initiates a task if prerequisites are complete.

All endpoints require JWT authentication and resolve the participant context before delegating to TaskQueue.

Response Management API

The response management API ensures secure creation and modification of quiz and review responses.

POST /responses – Creates a new response. GET /responses/:id – Retrieves an existing response. PATCH /responses/:id – Updates an existing response.

Security measures include ownership verification and task order enforcement to prevent unauthorized or out-of-sequence submissions.

Task Enforcement and Workflow

When a student attempts to start or submit a quiz:

A TaskQueue instance is initialized. Response maps are converted into task objects. Tasks are ordered sequentially. Completion of prior tasks is verified. Requests failing prerequisite checks are rejected.

This enforces strict task order without embedding logic directly into controllers.

Authentication and Authorization

All requests follow a layered processing pipeline:

JWT authentication decodes tokens and sets current_user. Authorization verifies permitted actions. Controller-level validation confirms resource ownership. Business logic execution handles task and response operations.

Multi-Round Support

The system supports multi-round assignments by scoping responses to both map_id and round. Existing responses are reused when appropriate, while new responses are created only when necessary, supporting quiz retakes and multi-round reviews.

Implementation Challenges

Several issues were encountered and resolved during development:

Callback Execution Order: Using prepend_before_action caused authorization to run before authentication. Replaced with before_action to correct the callback sequence. RSA Key Inconsistencies: Stale RSA keys caused JWT validation failures. Resolved by removing outdated key files and excluding them from version control. Test Initialization Conflicts: Mixed eager and lazy initialization in RSpec caused intermittent failures. Standardized lazy evaluation with dependency chaining. Consistency of Error Messages: Different layers returned conflicting 401 messages. Resolved by relying on the authentication layer to handle all unauthorized requests uniformly.

Testing

Model and request tests were implemented to validate:

Task completion logic Queue ordering Factory behavior API endpoint correctness Authentication and authorization checks

All tests executed successfully, resulting in 77 passing examples.

Future Work

Potential improvements include:

Deadline-aware task sequencing Partial progress tracking for quizzes Frontend progress indicators for task completion Support for additional task types Administrative tools for queue inspection and overrides

Team

Akhil Kumar Dev Patel Arnav Merjari

Mentor: Dr. Ed Gehringer

References

<references/> * Expertiza GitHub Repository * Ruby on Rails Guides * RSpec Documentation * JWT Ruby Gem