Add Issue Reporter widget for Monitor integration

[claytoncollie]

Summary

Add a client-side "Report Issue" widget to 10up Experience that allows users on client sites to submit issues directly to Monitor. This replaces MarkerIO as Fueled's default client-site reporting tool and routes issues through Monitor as middleware to Teamwork, GitHub, GitLab, Jira, etc.

Related

• Monitor issue: 10up/monitor#23 — Replace MarkerIO with Monitor-owned reporting
• Monitor PR: 10up/monitor#31 — Issue Reporter collection, API, UI, and integrations

What Monitor provides

Monitor PR #31 adds:

• POST /api/issues/create endpoint (authenticated via project x-api-key, same key used by SupportMonitor)
• Issues collection with structured fields: title, description, pageUrl, severity, category, screenshot, browser/device/OS, reporterEmail, externalIds
• Outbound integrations to Teamwork, GitHub, GitLab, Jira
• Monitor UI for viewing and managing issues

What 10up Experience needs to add

1. Issue Reporter widget

A MarkerIO-like floating "Report Issue" button that opens a form/modal on client sites.

Minimum fields:

• Title (text)
• Description (textarea)
• Page URL (auto-filled from window.location.href)
• Severity (select: low / medium / high / critical)
• Category (select: bug / ux / content / other)
• Screenshot (optional — file upload or canvas capture)
• Reporter email (optional)

2. API submission

Submit to Monitor's POST /api/issues/create endpoint using:

• x-api-key header — the same project API key already configured in SupportMonitor settings
• source: 'wordpress_experience' — to identify the submission origin

3. Configuration

• Use the existing SupportMonitor API key (no new credentials needed)
• Add an admin toggle to enable/disable the widget (default: disabled)
• The widget should only appear for logged-in users with appropriate roles (configurable)

Implementation notes

• The widget JS should be lightweight and self-contained
• It should work alongside the existing SupportMonitor daily report — they share the same API key but hit different endpoints (/api/reports/create vs /api/issues/create)
• Monitor also plans a non-WordPress JS snippet (@fueled/monitor-reporter) for non-WordPress sites — the widget UX should be consistent across both

Acceptance criteria

• Floating "Report Issue" button appears on configured sites
• Form submits to Monitor's /api/issues/create with correct auth
• Uses existing SupportMonitor API key — no additional configuration needed
• Admin toggle to enable/disable the widget
• Role-based visibility (configurable which roles can see the widget)
• source field set to wordpress_experience so Monitor knows the origin

[claytoncollie]

Monitor integration context

The Monitor side of this feature is tracked in 10up/monitor#23 / PR #31 (Phase 6 of the Monitor feature chain).

What Monitor PR #31 provides

• Issues collection — structured fields: title, description, pageUrl, severity, category, screenshot (URL), browser/device/OS, reporterEmail, source, externalIds
• POST /api/issues/create — authenticated via x-api-key header (same project API key already used by SupportMonitor for /api/reports/create)
• Outbound integrations — Monitor acts as middleware, forwarding issues to configured platforms (Teamwork, GitHub, GitLab, Jira) with external ID tracking
• Monitor UI — Issues tab on environment detail pages for viewing and managing submitted issues

API payload shape

{
  "title": "Button not working on checkout page",
  "description": "The submit button...",
  "pageUrl": "https://example.com/checkout",
  "severity": "high",
  "category": "bug",
  "screenshot": "https://...",
  "reporterEmail": "user@example.com",
  "source": "wordpress_experience",
  "browser": "Chrome 120",
  "os": "macOS 14.2"
}

Authentication

The widget should use the same API key already configured in the SupportMonitor settings page (Settings > General > Support Monitor). No new credentials needed — the key authenticates against the project in Monitor, and Monitor resolves the environment from the site URL.

Integration with existing SupportMonitor code

• The daily report goes to POST /api/reports/create
• Issues go to POST /api/issues/create
• Both use the same x-api-key header and the same base URL (SUPPORT_MONITOR_SERVER_URL constant or default https://monitor.10up.com)
• The widget is a separate feature from the daily report — they coexist independently

Non-WordPress path

Monitor also plans a JS snippet and @fueled/monitor-reporter npm package for non-WordPress sites. The widget UX should be kept consistent across both — same form fields, same API shape, same visual pattern.