[Feature] Public reports page + community flagging for suspicious reports

[necdetsanli]

Summary

Add a public “All reports” page where users can browse submitted ghosting reports (with privacy-safe constraints), and provide a way for users to report/flag suspicious, incorrect, or malicious entries for admin review.

This would improve transparency and make moderation more community-assisted, while still keeping the project privacy-first.

Motivation / use case

• Candidates benefit from seeing concrete examples and trends beyond aggregates, especially for lesser-known companies where stats are sparse.
• Admins benefit from community-driven detection of:
  • spam submissions
  • malicious/defamatory entries
  • clearly incorrect reports (wrong company/country)
  • duplicates that slipped through
• Self-hosters get a more complete “community platform” experience with built-in moderation signals.

The page should be designed to avoid turning into a “name and shame” platform while still being useful and aligned with the project goal: surfacing patterns and encouraging respectful hiring.

Proposed solution

Public page

• Add a new route, e.g.:
  • /reports — list view of reports
• Show only non-deleted reports (and possibly exclude admin-flagged depending on policy).
• Privacy-safe presentation:
  • Never show raw IP data (already not stored)
  • Consider showing only coarse metadata:
    • company name
    • country
    • stage
    • job level
    • position category
    • position detail (consider truncation or stricter limits)
    • created date (consider relative time)
    • daysWithoutReply (optional)
• Pagination and filters (initial version can be minimal):
  • country
  • company (search)
  • stage, job level, category
  • sort: newest / most reported company (optional)

User reporting

• Each report row/card has a “Report” action.
• On click:
  • Open a small dialog with optional reason categories:
    • spam / bot
    • wrong company
    • wrong country
    • duplicate
    • abusive content
    • other (free text, length-limited)
• POST to a new endpoint, e.g.:
  • POST /api/report-flags (or /api/reports/[id]/flag)
• Abuse protection:
  • Rate limit flag submissions per IP/day (hashed IP like existing rate limiting)
  • Add honeypot + minimum fill time on the flag form too
• Admin workflow:
  • Show flagged counts/reasons in /admin list
  • Add ability to view flag details and quickly:
    • mark as reviewed
    • soft-delete / hard-delete the report
    • optionally merge companies (future enhancement)

Data model (likely)

• Add a new table like ReportFlag:
  • id
  • reportId (FK)
  • reason enum + optional details
  • createdAt
  • ipHash (optional; hashed only, no raw IP)
  • status (OPEN/REVIEWED) or simply count aggregation
• Alternatively, store aggregated counters on Report for MVP:
  • flagCount, lastFlaggedAt
  • and keep details only in logs (but a DB table is cleaner for admin UX)

Alternatives considered

• Keep only aggregated stats (current approach) and add a “report company listing errors” contact link (simpler, but less actionable).
• Allow users to report only the company, not individual reports (reduces precision for moderation).
• Expose reports only to admins (safer, but misses transparency/community moderation).

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?

Maybe

If Yes/Maybe, describe briefly

• Introduces new public page /reports and new API endpoint(s) for fetching reports and submitting flags.
• Requires careful privacy decisions (what fields are shown publicly) and anti-abuse protections for flagging.

Additional context

• This feature should be implemented with a privacy-first and safety-first stance:
  • avoid enabling targeted harassment
  • ensure content limits and moderation controls are strong
  • consider excluding overly specific/identifying position details by policy if needed