Bug Reports

Bug Reports

"Report Me Not" is the in-app bug report system. Any logged-in user can file a bug from anywhere on the site and then hold a private, threaded conversation with staff until it is resolved. Staff get a full triage workspace in the admin panel. It is a lightweight ticketing system, not email: everything happens in the app, with optional push notifications.

Player reports (reporting another user for bad behavior) share the same ticket tables but are a separate flow; see Player Reports.

Filing a bug

The Report Bug button (bug icon) sits at the bottom of the sidebar on every page. Logged-out visitors are sent to the login page first. Clicking it opens a modal with a subject (up to 160 characters) and a description. On submit the report is created, you become its reporter, and staff are notified.

Your reports (/reports)

Once you have at least one report, a red Reports link appears in the sidebar with an unread badge counting reports that have new activity since you last opened them. The /reports page is a two-frame messenger:

• The list is split into Active and Closed, each entry showing its #id, subject, status, and any labels.
• Opening a report shows the full thread. You can reply, and a reply on a report that was resolved or closed automatically reopens it.
• You can invite other users as collaborators (up to 4) to add detail to your report.
• When a report is resolved you can reopen it, or leave a satisfaction rating (good or bad, with an optional comment). The rating stays editable for 7 days, then locks.

Statuses are open, pending, resolved, and closed. You see the status, labels, and the conversation; staff-only details (priority, assignee, internal notes) are never shown to reporters.

Staff triage (admin panel)

Moderators and admins get a Bug Reports tab in the admin panel. It lists every report with filters (status, label, assignee, and a text search) and sorting (most recent, status, opener, who it is awaiting, or priority). For each report staff can:

• Reply publicly to the reporter, or post an internal note that only staff can see (internal notes never reopen the report or notify the reporter).
• Assign the report to a staff member and set a priority (low, normal, high, urgent). Assignment and priority changes are recorded as internal notes.
• Apply labels. Seven are built in: Bug, Crash, UI, Feature Request, Question, Duplicate, and Wontfix. Admins can add custom labels and recolor or rename any label; the built-in labels cannot be deleted.
• Insert a canned response (saved macro) when replying, and manage the macro list.
• See an "awaiting staff" or "awaiting user" hint derived from who sent the last public message.

Notifications

When push notifications are configured (see Configuration), staff are pushed on a new report, participants and staff are pushed on a public reply, and an invited or newly assigned user is pushed directly. Push degrades silently when credentials are absent; the in-app unread badge always works.

For self-hosters

• The feature needs migration sections 39 and 40 applied (see Database Guide). Pages render before the migration is applied, but the reports list and admin tab need the tables.
• The relevant tables are bug_reports, bug_report_messages, bug_report_participants, bug_report_labels (seeded with the 7 built-ins), bug_report_label_map, and bug_report_macros.
• API routes are listed in API Reference.

Roadmap

Anonymous (logged-out) bug reporting is planned. The database already reserves the columns for it, so enabling it later is a code-only change.