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

Expertiza: Response & Task Ordering System

Course: CSC 517 — Object-Oriented Design and Development
Institution: North Carolina State University
Semester: Spring 2026

Table of Contents

1. Background
2. Project Overview
3. Implementation
4. Testing
5. Demo Video
6. References

Background

Expertiza is an open-source, peer-review-based learning management system developed and maintained at North Carolina State University. It is used in courses across NCSU and other institutions to facilitate collaborative learning through structured peer review, team assignments, and iterative feedback cycles.

The platform allows instructors to create assignments with multi-round review workflows, where students submit work, review their peers' submissions, and receive feedback. Expertiza is built on Ruby on Rails and has an active community of student contributors who extend and improve its functionality each semester as part of graduate coursework in CSC 517.

The system manages complex entities including assignments, participants, response maps, and responses — all coordinated through a carefully structured authorization and task-ordering pipeline.

Project Overview

This project is a reimplementation of key backend components of Expertiza as part of Program 3 in CSC 517. The goal was to redesign and improve three interconnected areas of the system:

• Task Ordering — enforcing that participants complete tasks in a defined sequence before proceeding to subsequent ones
• Student Task Management — providing students with a clear view of their current tasks, queue position, and next actionable item
• Response Creation & Authorization — ensuring that only authorized participants can create or modify responses tied to their assigned review maps

The reimplementation emphasizes clean object-oriented design, proper separation of concerns, RESTful API conventions, and comprehensive test coverage using RSpec and Rswag.

Implementation

Task Ordering

A dedicated task ordering module was introduced under app/models/task_ordering/ to encapsulate the logic for determining which tasks a participant is eligible to complete. Key classes include:

Class	Responsibility
BaseTask	Defines the shared interface for all task types, including completion status and map membership checks
ReviewTask	Extends BaseTask to handle review-specific logic tied to ReviewResponseMap
QuizTask	Extends BaseTask to handle quiz participation tasks
TaskFactory	Implements the factory pattern to instantiate the correct task type based on the response map class
TaskQueue	Orchestrates the ordered sequence of tasks for a given participant and assignment, exposing map_in_queue? and prior_tasks_complete_for?

This design replaces ad-hoc task eligibility checks that were previously scattered across controllers, centralizing the logic in a maintainable and testable module.

Student Tasks Controller

The StudentTasksController was implemented to give students visibility into their assignment workload. It exposes the following endpoints:

Method	Path	Description
GET	/student_tasks/list	Returns all tasks for the current user
GET	/student_tasks/view	Returns details for a specific participant task
GET	/student_tasks/queue	Returns the ordered task queue for an assignment
GET	/student_tasks/next_task	Returns the next incomplete task
POST	/student_tasks/start_task	Marks a task as started if queue order allows

Authorization is handled via JWT token authentication inherited from ApplicationController, with action_allowed? overridden to enforce participant-level access control.

Responses Controller

The ResponsesController manages the creation and updating of peer review responses. Key design decisions include:

• Authorization via before_action — find_and_authorize_map_for_create runs after authenticate_request! to ensure current_user is available before map ownership is verified
• Task order enforcement — the enforce_task_order! helper delegates to TaskQueue to confirm the participant is eligible to respond before allowing creation or update
• Round-aware response handling — responses are scoped by map_id and round, supporting multi-round review workflows

Method	Path	Description
POST	/responses	Create a new response for a review map
GET	/responses/:id	Retrieve a specific response
PATCH	/responses/:id	Update an existing response

Authorization & JWT Authentication

Authentication is handled via RSA-signed JWT tokens using the JsonWebToken class. The JwtToken concern decodes the token from the Authorization header on every request and sets current_user. The Authorization concern then runs action_allowed? to determine whether the authenticated user is permitted to perform the requested action.

A key architectural fix during this implementation was ensuring that find_and_authorize_map_for_create uses a standard before_action rather than prepend_before_action, so that authenticate_request! always runs first and current_user is reliably available before ownership checks occur.

Testing

All components were tested using RSpec for unit and integration testing and Rswag for API-level request specs that simultaneously generate OpenAPI documentation.

Model Specs

Located under spec/models/task_ordering/:

Spec File	Coverage
base_task_spec.rb	Tests shared task interface and completion logic
review_task_spec.rb	Tests review-specific map membership and completion status
quiz_task_spec.rb	Tests quiz task eligibility and completion detection
task_factory_spec.rb	Tests correct task instantiation by response map type
task_queue_spec.rb	Tests queue ordering, map_in_queue?, and prior_tasks_complete_for?

Request Specs

Located under spec/requests/api/v1/:

Spec File	Scenarios Covered
student_tasks_controller_spec.rb	200 success, 401 unauthorized, 404 not found across all five endpoints
responses_controller_spec.rb	201 created, 401 unauthorized, 403 forbidden, 404 not found for POST; 200, 401, 403 for GET and PATCH

Notable Testing Challenges & Fixes

During development, several non-trivial testing issues were encountered and resolved:

prepend_before_action ordering bug

find_and_authorize_map_for_create was running before authenticate_request!, causing current_user to always be nil and returning 401 even for valid tokens. Fixed by switching to a standard before_action.

Stale rsa_keys.yml

A pre-existing RSA key file caused JWT decode failures in tests because the keys used to encode tokens at spec time differed from those loaded at class initialization. Resolved by deleting the stale file and adding it to .gitignore.

let! vs let scoping in RSpec

Eager let! declarations for user records caused token encoding to reference a different object instance than the one persisted in the database, leading to User.find failures during authentication. Fixed by using lazy let with a let! dependent that forces creation through the dependency chain, mirroring the pattern used in the passing student_tasks_controller_spec.rb.

Demo Video

Demo Video: [Link to be added]

The demo will cover:

• A walkthrough of the task ordering system and how it enforces sequential task completion
• Live API calls demonstrating the student tasks endpoints
• Response creation and authorization flow including JWT authentication
• RSpec and Rswag test suite execution showing all passing examples

References

• Expertiza GitHub Repository
• Ruby on Rails Documentation
• RSpec Documentation
• Rswag GitHub Repository
• JWT Ruby Gem
• North Carolina State University, CSC 517 Course Page
• Fowler, M. (2018). Refactoring: Improving the Design of Existing Code (2nd ed.). Addison-Wesley.
• Metz, S. (2018). Practical Object-Oriented Design: An Agile Primer Using Ruby (2nd ed.). Addison-Wesley.

---

Last updated: March 2026 | Contributors: Akhil Kumar et al. | CSC 517, Spring 2026, NCSU