Skip to main content

Abuse Reports

The Abuse Reports queue collects reports submitted by end users — typically against copyright or safe-song entries that look wrong, fraudulent, or malicious. Admins triage each report and mark it resolved (the report was valid and we acted on it) or rejected (the report was spurious).

Where to find it​

Admin sidebar → Abuse Reports (/abuse-reports).

Quick start​

  1. Open Admin → Abuse Reports.
  2. Filter by status using the tabs — default is Pending.
  3. Read the Reason text and follow the Proof link, if provided.
  4. Click Resolve to mark the report as valid and acted upon, or Reject to dismiss it.
  5. Check the All tab to audit past decisions.

Detailed walkthrough​

Status filters​

A tab bar at the top toggles between:

  • Pending — default; unreviewed reports.
  • Resolved — reports an admin accepted and acted on.
  • Rejected — reports an admin dismissed as invalid.
  • All — everything.

Report rows​

Each pending report shows:

  • Reporter display name / user ID (via Reported by).
  • Reason — free-text field the user submitted.
  • Proof — optional URL (YouTube link, screenshot host, etc.). Rendered as a clickable link when present.
  • Timestamp of submission.
  • Two buttons: Resolve and Reject.

Resolved and rejected rows also display the resolving admin's ID (resolved_by) and the resolved_at timestamp.

Decision actions​

Both Resolve and Reject hit the same endpoint with different status values. The UI optimistically refetches after the call so the row moves to the right tab immediately.

Common scenarios​

  • Copyright false-positive — user reports a song flagged as unsafe that they believe is actually safe; investigate on the Copyright Review page, then resolve the abuse report.
  • Coordinated report spam — if multiple users submit near-identical reports against the same track, cross-reference with the song in the Copyright Reports queue before acting.
  • Bad-faith report — reject with no action and the row moves to the Rejected tab for later audit.

Permissions​

ActionPermission
View reports (all statuses)support:read
Resolve / reject a reportsupport:edit

Dashboard entry requires admin:access. System admins (is_system: true) get every admin permission implicitly.

API​

UI actionGraphQLREST
List abuse reports (filtered)— (REST only)GET /v1/admin/abuse-reports?status={pending|resolved|rejected|all}
Submit an abuse report (user side)— (REST only)POST /v1/abuse-reports
Resolve / reject a report— (REST only)PATCH /v1/admin/abuse-reports/\{id\} with { status: "resolved" | "rejected" }

Abuse reports are a REST-only surface today — no GraphQL resolver is exposed.

Tips & gotchas​

  • There is no "undo" — once resolved or rejected, re-opening a report requires a DB change. Be deliberate.
  • The Proof link is user-supplied and untrusted. Open it in an incognito window, never paste it into an authenticated tab.
  • The UI does not surface how many times the reported entity has been reported previously. Cross-reference manually using Copyright Reports.
  • resolved_by stores the admin user ID, not display name. Use the Users page to resolve IDs.