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

From Expertiza_Wiki
Jump to navigation Jump to search

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 originally covered both frontend and backend work for improving the Student Task View in Expertiza. In this repository, the work is limited to the backend Rails API. This backend-only version preserves the original project context while focusing on API behavior, authorization, response composition, revision-request workflows, and automated testing.

The goal of this effort was to stabilize and complete an already-started backend 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 secure backend endpoints.

Tech Stack

  • Backend: Ruby on Rails (API)
  • Database: MySQL
  • Testing: RSpec

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

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.

In addition, the backend lacked sufficient automated tests. Without strong request, model, and routing coverage, regressions in task retrieval, authorization, deadline handling, or review-related data could silently break the student experience.

This backend work therefore focused on delivering a reliable API for the Student Task View. The major backend 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.
  • 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, and routing 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 backend-supported view.

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.

Task Detail Retrieval

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

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.

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.

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.
  • Missing optional review or questionnaire data does not cause endpoint 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.

Design

Student Task Overview Design Diagram

This backend-oriented 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.

Backend Overview

  1. Rails API Layer
    • Exposes student task list and detail endpoints.
    • Handles authentication, ownership checks, and instructor-only revision review permissions.
    • 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.
    • Gracefully handles missing optional data.
  3. MySQL Database System
    • Stores assignments, participants, teams, revision requests, and related task data.
    • Provides the persistent relationships used to assemble student task responses.

Request / Response Flow

  • The authenticated student requests GET /student_tasks/list.
  • The API resolves the current user’s AssignmentParticipant records.
  • The StudentTask model composes the response payload for each task.
  • The API returns serialized task data for task-list rendering.
  • For task details, GET /student_tasks/:id and GET /student_tasks/view?id=:id return the detailed payload for the owned participant record.
  • For revision requests, POST /student_tasks/:id/request_revision creates a persisted request when the task is eligible.

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.

Design Principles

In improving the backend 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.

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.

Encapsulation & Modularity

Authorization, payload composition, revision-request validation, and route definition are separated into focused backend units. This keeps business rules localized and makes regression testing more effective.

Test Plan

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

Relevant Links

Repos

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
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

Future Scope

With the Student Task backend stabilized around AssignmentParticipant-backed task composition, 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>
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2026_-_E2602._Reimplement_student_task_view&oldid=167565"