View Feedback

Feature Owner : Joylynne Esportuno
Module : Notifications (Updates)
Priority : P3
Sprint #6 : Fully Implemented
Date : July 2, 2026

EXECUTIVE SUMMARY

What is this feature ?
View Feedback routes creators from a notification to reviewer feedback in the quest editor.

Why does it matter ?
Creators need to quickly find reviewer comments without hunting through the canvas.

What's the MVP scope ?
Notification deep link opens the relevant quest/canvas feedback view.

1. USER PAIN POINT & SOLUTION

Without View Feedback

Creators may receive feedback but not know where to address it.

Pain Point

Emotional : Feedback feels scattered.
Functional : Manual navigation wastes time.
Business Impact : Review turnaround slows down.

Current State (Already implemented)

Clicking a notification opens the quest feedback surface on the quest editor.

Marketing Hook

"Jump straight from review alerts to the feedback that matters."

2. 4D FRAMEWORK MAPPING

Diagnose

Shows exactly which quest needs revision.

Design

Keeps reviewer notes attached to content context.

Develop

Uses notification links and feedback panel routing.

Deliver

Speeds creator review-response cycles.

3. USER FLOWS

Entry Point

Creator notification bell.

Success Criteria

Notification click opens quest editor feedback area and marks notification read.

Main Flow

1. Reviewer leaves comment or requests changes.

2. Notification is created.

3. Creator clicks notification.

4. App marks notification read.

5. Router opens linked quest feedback view.

Edge Cases

• No link : Keep notification visible and avoid broken navigation

• API error : Keep unread state or roll back local update

• Permission denied : Show access denied

Decision Points

• IF notification link has feedback query, open feedback panel

• ELSE route to quest overview/editor fallback

4. INFORMATION ARCHITECTURE

Primary Information

• Quest title

• Feedback status

• Reviewer comment context

Secondary Information

• Notification read state

• Comment timestamp

Tertiary Information

• Reviewer identity and resolved state

Actions

Primary CTA : Open feedback
Secondary Actions : Mark read, resolve comment

5. WIREFRAMES

Excluded — Feature fully implemented.

6. WIREFLOWS

Excluded — Feature fully implemented

7. PROTOTYPE

Excluded — Feature fully implemented

8. BACKEND SCHEMA

Database Tables

• notifications

• reviewer comment tables

• quests

Indexes

-- Primary lookup: user's notifications (most common query)
CREATE INDEX IF NOT EXISTS idx_notifications_to_user_id
    ON notifications(to_user_id);
 
-- Unread notifications filter (for badge counts)
CREATE INDEX IF NOT EXISTS idx_notifications_to_user_unread
    ON notifications(to_user_id, is_read) WHERE is_read = FALSE;
 
-- Chronological ordering (recent first)
CREATE INDEX IF NOT EXISTS idx_notifications_created_at
    ON notifications(created_at DESC);

Constraints

• Notifications must belong to the authenticated recipient.

• Feedback comments must belong to a quest the creator/reviewer is authorized to access.

• Stale links should fail safely without exposing hidden comment data.

9. API ENDPOINTS

Endpoint 1: GET /api/notifications/get-notifications

Purpose: Loads creator notifications, including review feedback links.
Auth: Authenticated user.
Frontend Use: Notification bell/list rendering.

Endpoint 2: POST /api/notifications/update-notifications

Purpose: Marks the clicked notification as read.
Auth: Notification owner only.
Frontend Use: Called before or during navigation to feedback.

10. DATA REQUIREMENTS

Frontend Needs

• Notification ID, title, body, type, read state, created timestamp, and link.

• Quest ID from the notification link or route params.

• Feedback panel open/closed state.

• Comment list, resolved status, author metadata, and timestamps when loaded.

API Calls Frontend Will Make

• Load notifications on bell open/poll interval.

• Mark clicked notification read.

• Load reviewer comments after reaching the editor.

Caching Strategy

• Notification data should be refreshed after mark-read. Comment data may be cached per quest during the editor session but should refetch after create/resolve actions.

11. PERFORMANCE CONSIDERATIONS

Database Optimization

• Notification queries should filter by recipient and order by created date. Comment queries should filter by quest ID and avoid loading unrelated feedback.

Client Optimization

• Do not load full reviewer comment data for every notification item. Load feedback details only after navigation to the relevant quest/editor.

Caching Strategy

• Use notification polling/manual refresh for the bell. Avoid aggressive caching of unread counts because read actions change them frequently.

API Response Time

• Notification list should load quickly enough for bell interaction. Feedback panel can show a loading state while comments are fetched.

12. SECURITY & AUTHORIZATION

Who Can Access This Feature?

• Creator: Can view feedback on owned quests.

• Reviewer Can access comments through review flows.

• Learner: No access.

Authorization Logic

• Notification API must return only notifications for the authenticated recipient. Feedback/comment APIs must verify quest ownership or reviewer role/scope.

13. ERROR HANDLING

401 Unauthorized: Redirect to sign-in or show session expired. Keep the notification unread if the user never reaches the feedback destination.

403 Forbidden: Show access denied when the creator does not own or cannot edit the quest. Do not reveal reviewer comment content to unauthorized users.

404 Quest Not Found: Show a missing quest message and keep the notification available for reference.

404 Comment Not Found: Open the quest feedback panel if possible and show a message that the specific comment may have been deleted or resolved.

14. TESTING CHECKLIST

Happy Path

• Notification created from reviewer action.

• Creator click marks read.

• Deep link opens quest editor.

• Feedback panel opens.

Edge Cases

• Unauthorized user blocked.

• Missing comment falls back to quest feedback view.

• Mark-read failure rolls back unread state.

• Stale notification link does not crash route.

15. OPEN QUESTIONS

For Frontend:

• Should deep links scroll to a specific comment thread?

• Should the feedback panel open as a sheet, modal, or inline canvas panel long-term?

For Backend:

• Should email links match in-app feedback links?

• Should notifications store comment_id separately from the link URL?

16. OUT OF SCOPE

• Browser push notifications and exact comment scroll targeting.

17. SUCCESS METRICS

• Notification click-through rate

• Review turnaround time

• Unresolved comment count

18. DEPENDENCIES

This feature depends on:

• Notifications table and bell UI

• Reviewer comment APIs

• Quest editor feedback/comment panel

• Review status/comment creation flows

These features depend on this:

• Review Alert click-through

• Creator review turnaround workflow

• Reviewer feedback resolution tracking

19. TIMELINE & OWNERSHIP

Backend: Joylynne Esportuno
Frontend: Joylynne Esportuno & Jethro Lagmay
QA: Uriel Tribiana
Estimated Completion: Fully implemented