[Feature] Admin: paginated full report list + safe DB operations (edit/reassign/merge)

[necdetsanli]

Summary

Improve the admin dashboard so admins can view all reports with proper pagination and perform direct database operations from the UI (moderation + safe bulk actions), without needing Prisma Studio or manual SQL.

Motivation / use case

• Admins need a reliable way to review and manage reports at scale:
  • view the full dataset (not only a small “latest” slice)
  • search/filter to find specific reports quickly
  • fix obvious data issues (wrong company/country, duplicates) in a controlled way
• Reduces operational risk:
  • avoids ad-hoc DB edits via Prisma Studio/SQL in production
  • provides an auditable, consistent workflow for moderation and cleanup
• Helps keep data quality high, which improves public stats and trust.

Proposed solution

Admin reports list (pagination + filters)

• Update /admin to support paging through the full report set:
  • server-driven pagination (cursor or offset-based) with stable sorting (createdAt desc, tie-breaker id)
  • show total count (optional) and current page size
• Add filters/search:
  • status (ACTIVE/FLAGGED/DELETED)
  • country
  • stage / job level / category
  • company name search (normalized)
  • date range (optional)
• Add sort options (optional): newest, oldest, flagged first

Direct DB operations from admin UI (safe, constrained)
Keep operations explicit and minimal, with SRP-friendly server modules and strong guardrails:

• Existing moderation actions remain:
  • flag + reason
  • soft-delete
  • hard-delete
• Add controlled “data correction” actions:
  • Edit report fields (limited set):
    • stage, jobLevel, positionCategory, positionDetail (length constrained), daysWithoutReply, country
  • Reassign report to a different company (select existing company)
  • Merge companies (admin tool):
    • pick source company + target company
    • move all reports to target
    • optionally delete source company if it has no remaining reports
• Bulk actions (optional, later):
  • bulk soft-delete/hard-delete selected reports
  • bulk reassign company (risky; probably “later”)

Security & safety

• All admin mutations:
  • require valid admin session
  • enforce host allow-list
  • CSRF-protected
• Add rate limiting to admin mutation endpoints if needed.
• Keep an audit trail (recommended):
  • store moderatedByAdminId (already present) and timestamps
  • optionally add an AdminAuditLog table for “edit/merge/reassign” events

API changes

• Add endpoints (examples):
  • GET /api/admin/reports?cursor=...&limit=...&filters=...
  • PATCH /api/admin/reports/[id] (edit report fields)
  • POST /api/admin/companies/merge (merge tool)
  • POST /api/admin/reports/[id]/reassign-company (or use PATCH)
• Ensure inputs are validated with Zod schemas and that logs remain privacy-safe.

Alternatives considered

• Continue using Prisma Studio / manual SQL in production (not ideal, higher risk, not auditable).
• Provide only a bigger “latest reports” list without edits (helps visibility but doesn’t solve data correction).
• Build a separate “admin ops” CLI (powerful, but less accessible and easier to misuse).

Which part(s) of the project does this touch?

• Report form / submission flow
• Rate limiting / abuse protection
• Top companies listing & filters
• Admin dashboard / moderation
• Privacy / logging / config
• Documentation & developer experience
• Other / unsure

Database schema changes?

Maybe

API contract changes?

Yes

Existing user behaviour changes?

No

If Yes/Maybe, describe briefly

No response

Additional context

• This feature should reduce operational risk by making production data fixes:
  • constrained
  • validated
  • logged/audited
  • and accessible only through hardened admin routes
• Prefer incremental rollout:
  1. pagination + filtering
  2. safe per-report edits
  3. company merge/reassign tools
  4. bulk actions (optional)