CSC/ECE 517 Spring 2026 - E2608. Hierarchical list display

Mentors: Ed Gehringer and Akhilsai Chittipolu

This page documents our group implementation for E2608 (Hierarchical List Display) across Courses, Questionnaires, and Teams.

Problem Statement

The E2608 requirement was to implement a reusable hierarchical list display template for three specific Expertiza views:

• Course -> Assignments
• Questionnaire Type -> Questionnaires
• Team -> Team Members

The project description also identified that existing hierarchy handling relied on Node-based superstructure. The required direction was to reduce that dependency by using direct database queries for parent and child objects, returning hierarchy-ready JSON from the backend, and rendering nested views on the frontend with a consistent template.

In scope, this meant implementing the three hierarchy views above, ensuring they are backed by appropriate parent/child queries, and presenting them in clear expandable/grouped UI patterns.

Project Description

Expertiza frequently displays hierarchical data:

• Courses with nested assignments
• Questionnaire types with nested questionnaires
• Courses/assignments with nested teams and team members

Historically, these hierarchies were represented with a Node superstructure where each entity had an associated Node and parent pointer. This introduced additional object management and coupling that was not strictly necessary for rendering parent-child lists.

The project objective was to design and implement a reusable hierarchical display template where:

• Backend performs direct database queries for parent and child data.
• Backend returns JSON payloads suitable for hierarchy rendering.
• Frontend applies a common expandable-list pattern while allowing view-specific presentation styles.

In short, the project moves hierarchy rendering from Node-centric wiring to query-and-render patterns for maintainability and consistency.

Current Implementation (Before E2608)

Before this work, hierarchical data existed in the domain model but was not consistently presented as a parent-child UI pattern across modules.

Typical behavior before E2608:

• Different pages used different data-loading styles, including separate API fetches for related entities.
• Some views depended on fallback/static sample structures when complete nested payloads were unavailable.
• Parent-child relationships were not always exposed in a way that made generic expandable tables straightforward.
• Hierarchical behavior varied by page rather than following one reusable template.

Drawbacks in Previous Implementation

The pre-E2608 behavior created several practical issues:

• Inconsistent user experience: hierarchy expansion behavior differed across pages.
• Additional client complexity: pages needed extra mapping/fetch orchestration to build nested displays.
• Higher coupling to page-specific logic instead of reusable table patterns.
• Harder validation against real backend hierarchy data in some flows.
• More chance of stale UI state when child lists were refetched separately.

Shared Team Architecture Decision

Before implementation, the team agreed on a common hierarchy approach:

• Use eager loading on the backend to fetch parent-child data in fewer queries.
• Return hierarchy-ready JSON (parents with embedded child collections) so frontend pages do minimal reshaping.
• Keep a consistent UX goal for expandable/collapsible hierarchy views, while allowing page-specific rendering style (table expansion or embedded dropdown lists).

This shared approach keeps data retrieval efficient and makes hierarchy rendering consistent with the mentor's requested template style, without forcing a single UI widget across all pages.

Our Contribution

We implemented a unified hierarchical-list strategy across three views and aligned backend payloads with frontend rendering needs.

Summary of what we delivered:

• Unified parent-child rendering approach for three major modules.
• Backend responses shaped to support hierarchy directly, with eager-loaded associations where applicable.
• Frontend pages updated to consume nested or hierarchy-aware data using view-appropriate UI patterns.
• Verification using both UI behavior and real database checks.

View 1: Course -> Assignment Hierarchy

Goal

Display assignments nested under their parent courses without CourseNode/AssignmentNode style custom hierarchy components.

Implemented work

• Backend updated to return courses with associated assignments in one response.
• Frontend updated to consume nested assignment data from course payload.
• Frontend no longer depends on separate all-assignments fetch for this view.
• Minor delete-flow refinement: after successful assignment delete, assignment is removed from local frontend data instead of refetching assignments only.

Result

Course rows can expand into assignment lists through the common hierarchy pattern.

View 2: Questionnaire Type -> Questionnaire Hierarchy

Goal

Group questionnaires by questionnaire type and display questionnaires nested under each type.

Implemented work

• Implemented hierarchical questionnaire list from the Admin view.
• Admin can create, edit, update, and delete questionnaires in these types:
  • Review
  • Metareview
  • Author feedback
  • Teammate Review
  • Survey
  • Assignment survey
  • Global survey
  • Course survey
  • Bookmark rating
  • Quiz
• In questionnaire listing, admin can expand a dropdown per type to see the embedded list of questionnaire instances for that category.

Result

Questionnaire browsing follows the same parent-child model used in the other E2608 modules.

View 3: Team -> Team Member Hierarchy

Goal

Display team members nested under teams for a selected assignment context using real backend data.

Backend implementation

1. Teams filtering in index:
   • Added parent_id filtering support.
   • Added types filtering support (AssignmentTeam, MentoredTeam, etc.).
   • Added deterministic ordering by name and id.
   • Added eager loading with users and team-participant associations.
2. Team serialization:
   • Added parent_id in team JSON payload for hierarchy-aware consumers.
3. Backward-compatible params:
   • Added parent_id acceptance in team params.
   • Preserved compatibility by mapping assignment_id to parent_id when needed.

Backend code snippet

The following code snippet shows the core backend change that made the teams API hierarchy-aware:

def index
	@teams = Team.includes(:users, { teams_participants: :participant })

	if params[:parent_id].present?
		@teams = @teams.where(parent_id: params[:parent_id])
	end

	if params[:types].present?
		requested_types = params[:types].is_a?(Array) ? params[:types] : params[:types].to_s.split(',')
		normalized_types = requested_types.map(&:strip).reject(&:blank?)
		@teams = @teams.where(type: normalized_types) if normalized_types.any?
	end

	@teams = @teams.order(:name, :id)
	render json: @teams, each_serializer: TeamSerializer
end

Frontend implementation

1. Added dedicated Create Teams loader:
   • Loads teams using assignment context and allowed team types.
   • Loads assignment participants.
   • Maps API data into initialTeams and initialUnassigned structures required by the view.
2. Route wiring:
   • Create Teams route switched to the new loader so it uses real backend data instead of fallback-only behavior.

Real-data verification

Verified against DB via Docker Rails runner for Assignment id 1:

• Team 1 (parent_id=1):
  • cameron_fahey / Prince Langosh VM
  • rickie.hamill / Rep. Rosena Paucek
  • elease / Myrl Durgan
• Team 9 (parent_id=1):
  • jacinda / Joshua Raynor
  • lydia.monahan / Edward Jacobi
  • eddie / Halley Schinner VM

This confirmed end-to-end data correctness for the team hierarchy view.

Significance of these changes

These changes are significant because they move the teams view away from static or fallback-only data and make it reflect the real assignment context from the database. By filtering teams using parent_id and types, the backend now returns only the teams that actually belong to the selected hierarchy context. The eager loading also improves efficiency by reducing unnecessary queries when team members are rendered.

From a design perspective, this aligns the teams view with the overall E2608 objective of removing unnecessary hierarchy plumbing and replacing it with direct association-based queries and hierarchy-ready responses. It also makes the frontend easier to validate, because the displayed team-member relationships now match the actual persisted data instead of a page-specific mock structure.

Verification and Testing

The hosted deployment for our project is available at:

http://152.7.177.90:3000/

UI Testing for Course -> Assignment Hierarchy

Log in to the hosted system and navigate to the Courses page. Verify that a course row can be expanded to display the assignments that belong to that course. Also verify that after deleting an assignment, the assignment list updates correctly within the course hierarchy.

UI Testing for Questionnaire Type -> Questionnaire Hierarchy

Log in as an administrator and navigate to the Questionnaires page. Verify that questionnaire types are shown as parent categories and that each type can be expanded to display the questionnaires in that category. Also verify that the admin workflow for creating, editing, updating, and deleting questionnaires works correctly for the supported questionnaire types.

UI Testing for Team -> Team Member Hierarchy

Navigate to an assignment's Create Teams page and verify that the page displays real team data rather than fallback sample data. For Assignment 1, verify that Team 1 and Team 9 are shown with the correct members, and confirm that the correct members appear under the correct team for the selected assignment context.

References

• Expertiza GitHub repository
• Expertiza project wiki
• RSpec documentation
• Vitest documentation