Reference
Report a website problem
Report website problems with automatically included diagnostics, a private contact email and email follow-up.
First created Last updated
Report a website problem
October 9 enhancement status: implemented and checked locally; hosted setup and a real conversation check remain. The shared reporter now requires guest contact email, supports staff bot alerts configured in Admin and connects GitHub comments with email replies. Source and local checks do not establish provider configuration or inbox delivery.
This feature is for broken website behavior: a button that fails, an error during registration, or a page that does not render correctly. It is separate from the dashboard’s incident and safety reporting system. Reports are intended for the public Furries PH GitHub issue tracker.
Submit a useful report
The launcher remains available above open application dialogs, including nested planning forms. Use a click or keyboard navigation to open it without losing the underlying draft. The report form takes the highest layer above the launcher. Closing it returns focus to the launcher; application forms retain their normal Cancel, Close and Escape actions. Browser-layer changes retain the report draft and completed verification, and do not send a report automatically.
- Select the floating Report a problem button at the bottom center of the page.
- Your username and display/furry name are filled automatically from your login and shown read-only. Signed-out visitors are marked as guests and must enter a valid contact email. Signed-in reports use the verified account email privately. No manual name entry or GitHub account is required.
- Write a short summary and describe what went wrong. Add the actions needed to reproduce it and what you expected when you can.
- Select Send report. Recent diagnostic logs are included automatically; there is no review button or extra sharing checkbox. The text beside Send explains that your displayed profile names, report and diagnostics will be public. Complete the verification challenge if shown.
- Use the returned issue link to confirm delivery. A completed verification or attempted submission is not proof that GitHub received the issue.
Diagnostic details (optional preview) lets you inspect or remove diagnostic text before sending. You can leave it closed. The first Send captures the latest logs unless you edited that text. Its snapshot and reference stay unchanged during retries so an uncertain delivery can be checked safely. Your contact email is kept private; later email replies become public comments when that enhancement is configured.
Use the dedicated contact field for your email. Do not put contact details, legal names, passwords, access tokens, private messages, payment information or confidential incident evidence in the public title, description or diagnostics. Automatic redaction is imperfect. Share only information you deliberately choose to publish.
Continue the conversation by email
After staff or another person adds a new comment to your GitHub issue, the reporting bot emails the original contact address. The message includes the comment and public issue link. Reply from that same mailbox to add your new text as a public Reporter reply (via email) comment. You do not need a GitHub account.
Keep the email’s generated reply recipient intact. Do not forward or publish that address. Plain text is preferred; attachments are not forwarded. Common quoted history and signatures are removed, but you should still review the text before sending. Use private support for account recovery, receipts, payment disputes or sensitive matters.
Only new comments are forwarded. Editing or deleting a comment does not resend it, and the reporter bot’s own comments do not cause an email loop. The original mailbox stays bound to the report; a later retry cannot select another recipient. Guest email-format validation does not verify ownership or guarantee inbox arrival.
What diagnostics can explain
The implementation captures browser context and up to 200 recent console and network events, within a 40,000-character snapshot:
| Information | Use and limitation |
|---|---|
| Browser, language, viewport and pixel ratio | Helps identify browser compatibility and screen-layout problems. |
| Online state and supported network hints | Gives coarse connection context; it is not a connection trace. |
| Sanitized page location, capture time and available release metadata | Helps locate the affected surface and version without publishing full URLs. |
| Recent console debug/log/info/warning/error messages and uncaught failures | Covers events observed after the reporter loaded, within the buffer limit. |
| Fetch/XHR metadata, safe header names and redacted JSON previews | Gives sanitized destination, status and timing details. JSON previews are limited to 8 KiB and private fields are filtered. |
This is not a complete remote debugging session. It does not recover earlier console history, retain unlimited logs, inspect all system software or hardware, capture screenshots, read cookies/storage, or collect uploaded files and arbitrary request/response bodies. Buffer and text limits can omit older events.
A developer may still need reproduction steps, a controlled follow-up, or separate permission to inspect private operational evidence. Describing what you clicked remains useful even when diagnostics are empty.
Identity and delivery
The API resolves community-facing names and a confirmed account email from the signed-in account. It never publishes the contact email in the issue or staff alert. Account lookup/email failures stop signed-in submission; the form does not silently change it into a guest report. Native CMS login context is marked browser-provided and cannot select the reply mailbox. Missing usernames remain unavailable rather than being invented from email addresses.
The organization-owned Furries PH Site Reporter GitHub App is the service identity. It creates issues on behalf of visitors so they do not need GitHub accounts. App credentials remain on the backend and must never appear in a site bundle or public environment variable.
If sending fails
Keep the dialog open and use Retry connection when service configuration or connectivity is unavailable. Save report downloads your current report for your own records; saving a file does not create a GitHub issue. After an interrupted attempt, review any restored content before sending again.
If delivery is uncertain, preserve the original report and follow its recovery instructions before creating another. The API checks the original receipt; it does not blindly create a second issue. An issue link proves issue creation, while staff-message and email delivery require their own checks.
If a notice does not arrive, check spam and the report’s public issue. Do not repeatedly resend the report or email to force an answer. Platform administrators should check the saved destinations, webhook deliveries and reply routing. An unknown provider outcome is held for investigation rather than automatically sending the same message again.
Configure staff alerts
FPH administrators configure this in Admin → Site reports.
- In Staff destinations, use the exact EMS Telegram/Discord picker. Connect the Furries PH Discord server or Telegram account/staff group through its existing linking buttons, then select private staff channels/groups.
- For a Telegram forum group, enter Topic ID (optional) if the alert belongs in a specific topic; blank selects the general chat. Public attendee chats and personal chats are excluded.
- Set Reply email domain to the dedicated domain routed to the API. Add the optional Staff webhook inside Admin when required.
- Choose Save settings, then Test saved destinations and confirm Send test message for a deliberate bot test.
The API rechecks private destination eligibility and current bot permissions. Connecting a new destination refreshes the inventory without discarding unsaved settings. Reload saved settings restores the current server version after a conflict or uncertain save.
Staff alerts include the reviewed title, site, report reference and public issue link. They do not include the reporter’s contact address, private reply address or raw diagnostics. A saved setting or destination test does not establish the email round trip.
Operator release checklist
The detailed source runbook is ../partners-api/docs/SITE_REPORTING.md in the sibling API repository.
Before releasing the conversation enhancement, configure the GitHub App’s signed Issue comments webhook at https://api.furries.ph/hooks/site-reports/github with a matching server secret of at least 32 characters. Route the dedicated reply domain’s Cloudflare email catch-all to the API Worker and retain the existing platform outbound mail transport. Apply the conversation Durable Object migration and deploy through the repository release path.
Verify one explicitly authorized, harmless report: valid guest email → exact bot-created issue → Telegram/Discord/webhook alert → human GitHub comment → original inbox email → email reply → one bot comment. Confirm no public contact address, attachment, quoted history or echo loop. Replaying the same provider event must not duplicate its message.
Local verification exercises the real Worker with simulated providers, multiple private Telegram/Discord targets, signed webhook receipts, MIME email replies, restart persistence, rejected inputs and ambiguous-delivery recovery. Admin and EMS browser checks verify the shared picker and linking helpers. Keep those checks, screenshots, hosted deployment, real staff messages and actual inbox/reply evidence separate.
Documentation validation commands:
pnpm check
pnpm build