Sprint 62: Admin Page & Feedback Logic Review

Decisions

Context: The existing Admin feedback page processed status filters on the client side, but this conflicted with server-side pagination (20 items/page), causing feedbacks in the given status on other pages to be missed.
Choice: Add status query parameter to Identity findAll, propagate through the full pipeline (Identity→Gateway→Frontend)
Alternatives: Load all data at once on the client — inefficient as data grows
Code Paths: services/identity/src/feedback/feedback.service.ts, services/gateway/src/feedback/feedback.controller.ts, frontend/src/app/admin/feedbacks/page.tsx

Context: Admin dashboard stats (total/unresolved/bug) were aggregated based on the current 20-item page, resulting in inaccurate numbers
Choice: Add counts field to findAll response — always return full stats by status (OPEN, IN_PROGRESS, ...) and by category (cat:BUG, cat:GENERAL, ...)
Alternatives: Separate stats API — unnecessary additional call cost at current scale
Code Paths: services/identity/src/feedback/feedback.service.ts, frontend/src/app/admin/feedbacks/page.tsx

Context: Screenshots stored as Base64 Data URL in DB TEXT column, so minimizing size is important
Choice: canvas.toDataURL('image/webp', 0.65) — 25-35% size reduction vs JPEG, equal or better quality
Alternatives: Keep JPEG and just lower quality — WebP is always smaller at the same quality
Code Paths: frontend/src/components/feedback/BugReportForm.tsx

Where: services/identity/src/feedback/feedback.service.ts findAll()
When to Reuse: When needing to show filtering stats on a dashboard with a paginated API. Including counts in the list API response avoids additional calls.

Symptom: Status filter applied only within the current page's 20 items, missing feedbacks in that status on other pages
Root Cause: Server returns 20 items regardless of status, client filters within those
Fix: Filters must be applied at the server query level (WHERE clause)