CSC/ECE 517 Spring 2026 - E2602. Reimplement student task view

About Expertiza

Expertiza is a robust, open-source web platform designed to empower educational environments that emphasize project-based learning. It streamlines collaborative activities, such as peer reviews, surveys, and team assignments, into an engaging, interactive experience that supports both teaching and learning.

For instructors and mentors, Expertiza offers a comprehensive suite of tools to manage assignments, provide timely and constructive feedback, and track performance metrics. This enables educators to monitor student progress effectively and ensure optimal learning outcomes.

For students, the platform is designed with learner engagement at its core. It allows students to actively participate in tasks, collaborate seamlessly with peers, and evaluate each other's work. This approach promotes academic growth while also enhancing critical thinking, problem-solving, and teamwork skills.

Expertiza's flexible architecture makes it ideal for a wide range of educational scenarios, from individual assignments to complex group projects and dynamic peer-review processes.

Introduction

The E2602: Reimplement Student Task View project covers both frontend and backend work for improving the Student Task View in Expertiza. The backend provides a stabilized Rails API for composing and serving student task data, while the frontend delivers a complete React + TypeScript interface for students to view, navigate, and interact with their tasks.

The goal of this effort was to stabilize and complete an already-started implementation so that a logged-in student can retrieve reliable task data, understand the current stage of each assignment, view deadlines and feedback-related information, and perform supported actions through a fully integrated frontend and backend.

Tech Stack

• Backend: Ruby on Rails (API)
• Frontend: React + TypeScript
• Database: MySQL
• Backend Testing: RSpec
• Frontend Testing: Vitest, React Testing Library

Key Improvements

• Replace incomplete or inconsistent task responses with stable composed payloads built from live backend data
• Strengthen authentication and ownership checks for student task access
• Add support for revision request submission and instructor review workflows
• Preserve legacy endpoint compatibility while cleaning up supported routes
• Add automated backend test coverage for success paths, authorization failures, and invalid-resource handling
• Implement a React/TypeScript Student Task list view that fetches and renders all assigned tasks with live API data
• Implement a React/TypeScript Student Task detail view showing timeline, team, topic, feedback, and revision request actions
• Add comprehensive frontend test coverage for rendering, navigation, loading, error, and empty states

Problem Statement

The Student Task View in Expertiza depends on data composed from existing model relationships rather than from a standalone StudentTask table. The earlier backend implementation required hardening to ensure that task data was built accurately, returned consistently, and protected with proper authentication and ownership checks.

On the frontend, the existing code was untested and incorrectly implemented — the previous StudentTasks component was a topic signup sheet rather than a task view. It required a complete rewrite to properly consume the backend API and render the student-facing task experience.

In addition, both the backend and frontend lacked sufficient automated tests. Without strong coverage, regressions in task retrieval, authorization, deadline handling, or UI behavior could silently break the student experience.

The major challenges addressed were:

• Backend Integration: stabilize the student task endpoints so they return consistent live data derived from AssignmentParticipant and related Expertiza models.
• Task Composition: assemble assignment, course, team, topic, deadline, timeline, feedback, and review state into a format that downstream clients can consume reliably.
• Frontend Implementation: build a correct React/TypeScript task list and detail view that consumes the backend API.
• Action Support: implement revision request submission for students and review actions for instructors.
• Authorization and Ownership: ensure that students can only access their own task data and that instructor-only revision review flows are properly protected.
• Testing and Regression Prevention: add automated request, model, routing, and frontend tests to cover the success and failure paths.

User Stories

Task List Retrieval

As a student, I want to retrieve a list of all of my assignment tasks, so that I can see my current work in one place.

Acceptance Criteria:

• The backend provides a task list endpoint for the current logged-in student.
• Each returned task includes summary data needed for a task overview, including assignment, stage, and deadlines.
• The endpoint returns an empty list rather than failing when the student has no tasks.
• The frontend renders the task list in a table with assignment, course, topic, stage, deadline, and review grade columns.
• The frontend shows an empty state message when no tasks are returned.

Task Detail Retrieval

As a student, I want to retrieve a detailed view for a specific task that I own, so that I can view assignment, team, topic, deadline, and feedback information.

Acceptance Criteria:

• The backend provides a task detail endpoint for a single owned task.
• The legacy detail alias returns the same payload as the primary detail endpoint.
• Invalid task identifiers return a not-found response.
• The frontend detail page displays assignment title, course, stage badge, deadline, team members, timeline, and reviewer feedback.

Task Interaction

As a student, I want to request a revision for an eligible task, so that I can initiate a supported revision workflow when resubmission is allowed.

Acceptance Criteria:

• The backend exposes a revision request submission endpoint for owned tasks.
• Duplicate pending revision requests are rejected.
• Requests are rejected when the task does not allow revision submission.
• The frontend shows a revision request form when the backend indicates revision is available.
• The submit button is disabled until the student enters a comment.

Timeline and Stage Data

As a student, I want task payloads to include current stage, stage deadline, and timeline-related data, so that the system can represent progress and upcoming deadlines correctly.

Acceptance Criteria:

• Task payloads include current_stage, stage_deadline, deadlines, and timeline data.
• The frontend renders a timeline card with phase icons (submission, review, feedback) and status badges (completed, current, upcoming).
• Missing optional review or questionnaire data does not cause endpoint or UI failures.
• Unavailable grades resolve cleanly instead of raising exceptions.

Authorization and Ownership

As a student or instructor, I want student task and revision-request endpoints to enforce role and ownership rules, so that users can access only the data and actions they are authorized to use.

Acceptance Criteria:

• Requests without a valid JWT return 401.
• A student attempting to access another student's task receives 403.
• Only the assignment instructor can approve or decline a pending revision request.
• The frontend wraps both student task routes in ProtectedRoute to prevent unauthenticated access.

Design

Student Task Overview Design Diagram

This design focuses on composing Student Task View data from the existing Expertiza domain model rather than from a separate task table. The API layer retrieves AssignmentParticipant-backed records for the current student and enriches them with assignment, course, team, topic, deadline, and feedback information. The frontend consumes this composed API response and renders it through two views: a task list and a task detail page.

Backend Overview

1. Rails API Layer — exposes student task list and detail endpoints, handles authentication, ownership checks, and instructor-only revision review permissions, and supports revision request submission and resolution actions.
2. Domain Composition Layer — builds StudentTask payloads from AssignmentParticipant and related models, computes stage, deadline, timeline, and feedback-related fields, and gracefully handles missing optional data.
3. MySQL Database System — stores assignments, participants, teams, revision requests, and related task data, and provides the persistent relationships used to assemble student task responses.

Frontend Overview

1. StudentTasks (List View) — calls GET /student_tasks, renders a TanStack React Table with columns for assignment, course, topic, current stage, stage deadline, and review grade. Handles loading, empty, and error states.
2. StudentTaskDetail (Detail View) — calls GET /student_tasks/:id, renders assignment info, team members, stage timeline, reviewer feedback, submission feedback, and revision request form.
3. StudentTaskColumns — defines column renderers including clickable assignment name links and colored stage badges.
4. studentTaskTypes — TypeScript interfaces matching the backend as_json response shape.

Request / Response Flow

• The authenticated student navigates to /student_tasks.
• The frontend calls GET /student_tasks and renders the task table.
• Clicking an assignment name or "View Details" navigates to /student_tasks/:participantId.
• The frontend calls GET /student_tasks/:id and renders the detail page.
• For revision requests, the student fills out the form and the frontend calls POST /student_tasks/:id/request_revision.
• For task details via legacy alias, GET /student_tasks/view?id=:id returns the detailed payload for the owned participant record.

Simplified UML Diagram

This class relationship is a summary of the backend data model used in the implementation. A User can act as a student or instructor. A student owns AssignmentParticipant records, each of which links the student to an Assignment. Each Assignment belongs to a Course and may involve teams and topics. Team-related associations connect a participant to an AssignmentTeam and its members. RevisionRequest records connect to AssignmentParticipant, AssignmentTeam, and Assignment so that student revision requests can be persisted and reviewed by the assignment instructor. There is no dedicated StudentTask database table; instead, StudentTask is a composed backend abstraction built on top of existing Expertiza relationships.

Improved Implementation of Backend

The backend implementation was completed as a hardening and stabilization pass over an existing Student Task feature. The work focused on endpoint behavior, authorization, task composition, revision-request workflows, and regression coverage.

Action Permissions

Authorization checks were enforced throughout the student task and revision request flows.

Purpose: Ensure secure access to task data and revision actions through authentication, role checks, and ownership checks.

Key features:

• Returns 401 for requests without a valid JWT
• Prevents students from accessing another student's AssignmentParticipant-backed task data
• Allows the owning student to view their own revision request
• Allows assignment instructors to list and review revision requests for their assignments
• Restricts revision approval and decline actions to the assignment instructor

Task Retrieval

List Action: returns all tasks for the current logged-in student in a consistent composed format.

• GET /student_tasks
• GET /student_tasks/list

Detail Action: returns the detailed payload for one owned student task.

• GET /student_tasks/:id
• GET /student_tasks/view?id=:id

Revision Submission Action: creates a revision request for an eligible owned task.

• POST /student_tasks/:id/request_revision

Revision Review Actions: expose instructor-facing list, show, and resolve operations.

• GET /revision_requests?assignment_id=:assignment_id
• GET /revision_requests/:id
• PATCH /revision_requests/:id
• PUT /revision_requests/:id

Comprehensive Testing

Automated backend tests were added for the key request, model, and routing paths.

Request coverage includes:

• Successful task list retrieval
• Successful task detail retrieval
• Legacy detail endpoint retrieval
• Empty task list behavior
• Unauthorized access without a token
• Forbidden access to another student's task
• Invalid task ID handling
• Successful student revision request creation
• Duplicate pending revision request rejection
• Revision request rejection when resubmission is not allowed
• Instructor retrieval and filtering of revision requests
• Instructor approval and decline flows
• Invalid assignment, revision request, filter, and resolution status handling

Model coverage includes:

• Student task payload construction
• JSON serialization shape
• Participant lookup behavior
• Deadline parsing behavior
• can_request_revision rules
• Revision request validation and pending-request uniqueness rules

Routing coverage verifies:

• Student Task and Revision Request endpoints

Verification result:

• 56 examples, 0 failures

Enhancement: Relevant File Details

StudentTask.rb

• Implements composed student task payload construction from AssignmentParticipant records and related models.
• Includes participant, assignment, course, team, topic, status, deadline, timeline, permission, review grade, and feedback-related data.
• Handles missing optional review or questionnaire data gracefully.

RevisionRequest.rb

• Adds persistent revision request support for student task workflows.
• Associates revision requests with AssignmentParticipant, AssignmentTeam, and Assignment.
• Validates required comments, supported statuses, and uniqueness of pending requests.

Routes.rb

• Defines the supported student task endpoints, including list, detail, legacy view, and request_revision.
• Adds revision request routes for instructor review actions.
• Restricts the exposed route surface to endpoints actually supported by the backend.

Migration

• Adds the revision_requests table through db/migrate/20260322174500_create_revision_requests.rb.
• Persists request comments, status, and the foreign-key relationships required for student and instructor workflows.

Frontend Implementation

The frontend implementation delivers the complete student-facing interface for the Student Task View. The previous StudentTasks component was incorrectly implemented as a topic signup sheet and required a full rewrite. Two new views were built and fully integrated with the backend API.

New Files Added

File	Purpose
src/pages/StudentTasks/StudentTasks.tsx	Task list view — fetches and renders all student tasks
src/pages/StudentTasks/StudentTaskDetail.tsx	Task detail view — renders full task info, timeline, feedback, revision form
src/pages/StudentTasks/StudentTaskColumns.tsx	TanStack column definitions with stage badge rendering
src/pages/StudentTasks/studentTaskTypes.ts	TypeScript interfaces matching backend JSON shape
src/pages/StudentTasks/__tests__/StudentTasks.test.tsx	14 tests for the list view
src/pages/StudentTasks/__tests__/StudentTaskDetail.test.tsx	20 tests for the detail view

StudentTasks (List View)

The list view replaces the previous incorrect implementation with a proper student task dashboard. It calls GET /student_tasks on mount, feeds the response into a reusable Table component, and handles all UI states:

• Loading — table renders empty while the API call is in flight
• Empty — a "You have no tasks assigned" message is shown when the API returns no results
• Error — a danger alert is dispatched via Redux when the API call fails

Each row shows the assignment name as a clickable link, course, topic, current stage as a colored badge, stage deadline, and review grade. Clicking the assignment name or the "View Details" button navigates to /student_tasks/:participantId.

Student Task List View

StudentTaskDetail (Detail View)

The detail view calls GET /student_tasks/:id using the participant ID from the route. It renders:

• Assignment Info card — stage deadline, topic, review grade
• Team card — team name and all team members
• Stage Timeline card — each deadline phase with icons and status badges (completed, current, upcoming)
• Reviewer Feedback card — all submitted review comments with reviewer name and date
• Submission Feedback card — instructor grade and comment on the submission
• Revision Request card — shown only when can_request_revision is true; expands to a form with a comment textarea, submit button (disabled until text is entered), and cancel button

Student Assignment Detail View

App.tsx Routing Changes

Two routes were updated in src/App.tsx:

// List view
{ path: "student_tasks", element: <ProtectedRoute element={<StudentTasks />} /> }
 
// Detail view (changed from :assignmentId to :participantId)
{ path: "student_tasks/:participantId", element: <ProtectedRoute element={<StudentTaskDetail />} /> }

Both routes are wrapped in ProtectedRoute requiring at minimum Student role.

Design Principles

In improving both the backend and frontend for the Student Task View, the implementation follows software design principles that support maintainability, testability, and clear responsibility boundaries.

Single Responsibility Principle (SRP)

Controllers focus on request handling, authorization, and response rendering, while the StudentTask model is responsible for composing task payloads. RevisionRequest encapsulates revision-request persistence and validation rules. On the frontend, StudentTasks handles only list fetching and rendering, StudentTaskDetail handles only detail fetching and rendering, and StudentTaskColumns handles only column definitions.

Don't Repeat Yourself (DRY) Principle

Shared task composition logic is centralized so that list and detail endpoints rely on the same underlying behavior. Route aliases reuse the same detail payload contract rather than duplicating inconsistent behavior. On the frontend, the stageVariant helper is defined once in StudentTaskColumns and reused in both the list columns and the detail badge.

Encapsulation & Modularity

Authorization, payload composition, revision-request validation, and route definition are separated into focused backend units. On the frontend, TypeScript interfaces in studentTaskTypes.ts enforce compile-time checks across all components, keeping the API contract explicit and centralized.

Test Plan

Backend Tests

Test ID	Test Case	Description	Expected Results	Priority	Status
TC1	Verify Task List Retrieval	Authenticated student requests their task list.	Returns 200 OK with the current student's tasks in a consistent format.	High	Passed
TC2	Verify Task Detail Retrieval	Authenticated student requests an owned task by ID.	Returns 200 OK with the detailed student task payload.	High	Passed
TC3	Verify Legacy Detail Endpoint	Authenticated student requests /student_tasks/view?id=:id for an owned task.	Returns the same payload contract as the primary detail endpoint.	High	Passed
TC4	Verify Empty Task List Handling	Authenticated student with no AssignmentParticipant records requests the list endpoint.	Returns an empty list without server failure.	High	Passed
TC5	Verify Unauthorized Access Handling	Unauthenticated request is made to student task or revision-request endpoints.	Returns 401 Unauthorized.	High	Passed
TC6	Verify Forbidden Cross-Student Access	Student requests another student's task or revision request.	Returns 403 Forbidden.	High	Passed
TC7	Verify Invalid Task ID Handling	Authenticated student requests a non-existent task ID.	Returns 404 Not Found.	High	Passed
TC8	Verify Revision Request Creation	Student submits a valid revision request for an eligible owned task.	Creates the request and returns the new revision-request data with refreshed task payload.	High	Passed
TC9	Verify Duplicate Pending Revision Request Rejection	Student submits a second pending revision request for the same task context.	Rejects the duplicate request with a validation error.	Medium	Passed
TC10	Verify Instructor Review Actions	Assignment instructor lists, views, and resolves revision requests.	Authorized instructor actions succeed and invalid resolution attempts are rejected.	High	Passed

Frontend Tests

Test ID	Test Case	Description	Expected Result	Status
FTC1	Task table renders page heading	List view mounts correctly	"Student Tasks" heading present	Passed
FTC2	Task table renders rows	API returns 2 tasks	Both assignment names visible	Passed
FTC3	Task table renders course names	Course column populated	Course names visible	Passed
FTC4	Task table renders stage badges	Current stage column	Badges rendered with correct text	Passed
FTC5	Review grade shown when present	Task has grade	Grade value visible	Passed
FTC6	N/A shown when grade absent	Task has no grade	"N/A" visible	Passed
FTC7	View Details buttons rendered	2 tasks in response	2 View Details buttons present	Passed
FTC8	Loading state hides data	isLoading true	No task rows visible	Passed
FTC9	Empty state message shown	API returns empty array	"no tasks assigned" message shown	Passed
FTC10	Empty state hidden during load	isLoading true	No empty-state message shown	Passed
FTC11	Error dispatches danger alert	API returns error	Redux alert state shows danger variant	Passed
FTC12	View Details navigates correctly	Button clicked	Navigates to /student_tasks/10	Passed
FTC13	Assignment name link navigates	Link clicked	Navigates to /student_tasks/10	Passed
FTC14	API called on mount	Component mounts	GET /student_tasks called	Passed
FTC15	Loading spinner shown	isLoading true	Spinner and loading text visible	Passed
FTC16	Error state shown	API returns error	Error card with "Task Not Found" visible	Passed
FTC17	Danger alert on detail error	API returns error	Redux alert shows danger	Passed
FTC18	Back button on error navigates	Error state, back clicked	Navigates to /student_tasks	Passed
FTC19	Assignment title rendered	Detail loaded	Title matches API response	Passed
FTC20	Course name rendered	Detail loaded	Course name visible	Passed
FTC21	Stage badge rendered	Detail loaded	Badge shows current_stage	Passed
FTC22	Topic rendered	Detail loaded	Topic name visible	Passed
FTC23	Team name and members rendered	Detail loaded	Team card shows all members	Passed
FTC24	Timeline card rendered	Detail with timeline	All timeline entries visible	Passed
FTC25	Timeline status badges rendered	Detail with timeline	completed and current badges shown	Passed
FTC26	Reviewer feedback rendered	Detail with feedback	Comment and reviewer name visible	Passed
FTC27	Submission feedback rendered	Feedback present	Grade and comment shown	Passed
FTC28	Submission feedback hidden	Feedback null	Card not rendered	Passed
FTC29	Revision card shown	can_request_revision true	Revision card visible	Passed
FTC30	Revision card hidden	can_request_revision false	Card not rendered	Passed
FTC31	Revision form shows on click	Button clicked	Textarea and submit/cancel visible	Passed
FTC32	Revision form hides on cancel	Cancel clicked	Form hidden, button returns	Passed
FTC33	Submit disabled when empty	Form open, no comment	Submit button disabled	Passed
FTC34	Submit enabled after typing	Comment entered	Submit button enabled	Passed
FTC35	Existing revision status shown	revision_request present	PENDING badge visible	Passed
FTC36	Back button navigates	Back clicked	Navigates to /student_tasks	Passed
FTC37	API called with correct ID	Route has participantId 42	GET /student_tasks/42 called	Passed

Relevant Links

Repos

• Backend Repo: https://github.com/ravisatyarsg/reimplementation-back-end
• Frontend Repo: https://github.com/ravisatyarsg/reimplementation-front-end

Pull Requests

• Backend PR: https://github.com/expertiza/reimplementation-back-end/pull/322
• Frontend PR: https://github.com/expertiza/reimplementation-front-end/pull/161

Demo Video

• Test Demo Video: https://youtu.be/UUFo3mbIbBg

Developer Guidance

Backend

Setup & Run (via Docker)

Run the following commands from your project root to start the backend environment using Docker:

docker compose down
docker compose build --no-cache
SEED_DB=true docker compose up

Within the container

After starting the containers, access the Rails backend container and run the necessary setup commands:

docker compose exec app bash
bundle install
bundle exec rails db:migrate:reset
bundle exec rails db:seed
bundle exec rspec

Frontend

Setup & Run

Run the following commands to set up and start the frontend:

git clone https://github.com/ravisatyarsg/reimplementation-front-end
cd reimplementation-front-end
npm install
npm run dev

The frontend will be available at http://localhost:3000. The backend must be running on port 3002.

Running Frontend Tests

npm test
# Press 'a' to run all tests
# Press 'p' then type 'StudentTask' to filter to E2602 tests only
# 34 tests, all passing

Future Scope

With the Student Task View stabilized across both backend and frontend, there are several practical directions for future improvement.

Dedicated StudentTask Abstraction

Although StudentTask exists as a backend abstraction, it does not have a dedicated backing database table. A future dedicated task table could centralize derived state, improve analytics and auditability, and simplify certain API queries if the feature grows substantially.

Richer Feedback Aggregation

Future backend work could aggregate review comments, submission feedback, and grading summaries into a more explicit feedback structure so clients can consume that information without additional interpretation.

Customizable Task Workflow Engine

The current timeline and stage computation could evolve into a more explicit workflow engine that supports assignment-specific stage definitions, more flexible revision states, and richer progression rules.

Mentor

• Koushik Gudipelly <kgudipe@ncsu.edu>

Members

• Ravi Goparaju <rsgopara@ncsu.edu>
• Xiangjun Mi <xmi@ncsu.edu>