Reviewer Queue Dashboard & Status Workflow

Front Matter

  • Title: Reviewer Queue Dashboard & Status Workflow

  • Author: Jethro Magdaleno Lagmay

  • Reviewers: Sean Patrick Caintic

  • Creation Date: June 30, 2026

  • Status: Published

Introduction & Goals

Problem Summary: WyzQuests requires a centralized hub for platform reviewers to evaluate submitted quests. Previously, there was no unified interface or structured state machine to handle the transition of quests from submission to final publication. This feature implements the frontend dashboard for reviewers to claim and review quests, alongside the backend status workflow to securely handle approval and rejection states.

Goals & Non-Goals:

  • Goals:

    • Create a responsive Reviewer Queue Frontend displaying pending quests.

    • Build a dedicated dashboard for reviewers to view quest details, canvas logic, and associated data.

    • Implement a secure Status Workflow handling state changes (e.g., Pending → Approved/Rejected) using Supabase.

    • Ensure real-time or optimistic UI updates upon status changes.

  • Non-Goals:

    • Building the actual course/quest authoring tools (handled in separate modules).

    • Automated AI-based approvals or content moderation.

Glossary:

  • Reviewer Queue: The aggregate list of all quests currently awaiting evaluation.

  • Status Workflow: The defined lifecycle and state transitions of a quest within the database.

  • Canvas Logic: The visual representation of the quest's structure that reviewers must evaluate.

High-Level Architecture

System Diagram:

xAPI Export Flow for LMS-2026-06-30-050515.png

Technologies Used:

  • Frontend: React, Next.js

  • Backend / Database: Supabase (PostgreSQL)

  • Styling: [Tailwind CSS / Other]

  • State Management: [React Context / Zustand / React Query]

Detailed Design & Implementation

Data Model / Schema: The following changes/additions are required in Supabase:

  • quests table updates:

    • status (enum): Updates to include ['draft', 'pending_review', 'approved', 'rejected'].

    • reviewer_id (uuid, foreign key): Links to the user ID of the assigned reviewer.

  • reviews table (New):

    • id (uuid, primary key)

    • quest_id (uuid, foreign key)

    • reviewer_id (uuid, foreign key)

    • status_given (enum: 'approved', 'rejected')

    • comments (text): Feedback from the integrated commenting system.

    • created_at (timestamp)

API Specification:

  • GET /api/reviews/queue (or Supabase Client fetch)

    • Purpose: Fetches quests where status == 'pending_review'.

    • Response: Array of quest objects containing metadata and author details.

  • POST /api/reviews/status (or Next.js Server Action)

    • Purpose: Executes the Status Workflow.

    • Payload: { quest_id: string, action: 'approve' | 'reject', comments: string }

    • Auth: Requires active Supabase session with role == 'reviewer'.

Logic & Workflows:

  1. Queue Rendering: The Reviewer Queue Frontend fetches pending quests and paginates/filters them based on submission date or category.

  2. Evaluation: Reviewer opens a quest in the dashboard, loading the visual canvas logic and course content.

  3. Status Mutation (The Workflow):

    • Reviewer submits a verdict.

    • The system verifies the user's RBAC (Role-Based Access Control) permissions via Supabase Row Level Security (RLS).

    • A database transaction occurs: The quest's status is updated, and a permanent log is created in the reviews table with the reviewer's feedback.

    • The frontend removes the item from the queue view.

Infrastructure & Operations

Dependencies:

  • Supabase Authentication (for Reviewer role verification).

  • Supabase PostgreSQL Database.

  • Next.js App/Pages Router.

Monitoring & Alerting:

  • Monitor API failure rates on the status mutation endpoint.

  • Log Supabase RLS violations (e.g., unauthorized users attempting to approve quests).

Deployment Plan:

  1. Apply Supabase database migrations (create Enums, new tables, update RLS policies).

  2. Deploy Next.js frontend updates behind a feature flag (if applicable) or directly to the staging environment.

  3. Perform regression testing on the quest authoring side to ensure the new status flags do not break existing queries.

Testing & Quality Assurance

Test Strategy:

  • Unit Tests: Validate the status transition logic (e.g., preventing a 'draft' quest from being directly 'approved' without being 'pending').

  • Integration Tests: Verify that submitting an approval correctly writes to both the quests and reviews tables in Supabase.

  • E2E Tests: Simulate a reviewer logging in, accessing the queue, interacting with the canvas logic, and submitting a rejection with comments.

Known Limitations:

  • [e.g., Real-time queue updates are currently polled rather than pushed via Supabase Realtime.]

  • [e.g., Concurrent reviewing: Currently, two reviewers might open the same pending quest simultaneously.]

Maintenance & Support

Troubleshooting:

  • Issue: Quests not appearing in the queue. Fix: Check if the quest status was properly set to pending_review by the authoring module, and verify Supabase RLS policies allow the current user's role to read them.

  • Issue: Status update fails. Fix: Ensure the reviewer has provided mandatory feedback comments if rejecting a quest.

Changelog:

  • None yet.

Document Version:

  • 1.0 - Draft, Initial technical documentation for Reviewer Management System, 06/30/2026


Was this article helpful?