Public reports setup

Public reports are TrailsIQ's channel for a trail user — a hiker, mountain biker, cross-country skier — to file a maintenance report from the trail itself without needing an account. They go through a GPS-required wizard on their phone, snap a photo, and their report lands in your queue as pending review. A manager approves it (moves it to Open) or rejects it (deletes it). Once approved, it flows through the same maintenance pipeline as anything a crew member files.

For most organizations, public reports are the single biggest source of ground-truth issue data: hikers walk hundreds of miles a week, and one report per weekend is far more than any small crew can survey. MD,

        <<<'MD'

What are public reports?

A public report is a MaintenanceIssue created by an anonymous user via /report (the "TrailsIQ Report" app). It has the same shape as any other maintenance item — a title, a description, a location, an issue type, photos — but it enters the system in a special status: pending review. Pending-review items don't appear on the public map, on any trail's Show page, or in the default Maintenance list view. They wait in a moderation queue until a manager acts on them.

Public reports are gated per-organization. If you don't want to receive them, you flip a single toggle and your organization is hidden from the report wizard entirely — trail users pointing at your terrain won't be offered your org as a report target.

Enabling or disabling public reports

Public reports are on by default — with one exception. A workspace set up as a trail builder starts excluded, because the report app is where a hiker looks for whoever maintains the trail they are standing on, and for a building company that is usually the client rather than you. A workspace that does both starts included, like any operator.

Either way it is one checkbox. Open Settings → Public visibility and look for the toggle labeled:

Exclude from public report app

The description reads: "Hides this organization from public hikers — they won't see it in the report wizard, won't find it via 'near me' discovery, can't save it as a favorite, and the /hub/<slug> page returns 404. Your crew + the field app keep working normally."

The section is its own rather than part of Public daily report, and that is deliberate: a builder workspace switches the daily report off, so a control living inside it would be invisible to exactly the workspaces this default acts on.

Turning that toggle on does four things:

1. Your organization stops appearing in the report wizard's org picker (so the app can't route a report to you).
2. The /api/v1/public-report endpoint refuses any report targeting your org with an opaque "Trail not found." response — no leak that your org exists but has reports off.
3. Your public hub page at /hub/{slug} returns 404.
4. Your organization is dropped from "near me" discovery in the public app.

Everything else — the field app, the dashboard, invited members, existing trails — keeps working. This is a public-facing switch only.

What the trail user sees

The public report app lives at app.trailsiq.com/report (the same central URL for every organization — there is no per-org subdomain). It requires GPS on the phone; if the browser can't get a fix, the wizard tells the user to enable location permissions and try again.

Once GPS is granted, the flow is four steps:

1. Issue type — chips: Blowdown, Water / Mud, Erosion, Drainage, Signage, Tread Repair, Clear Corridor, Broken structure, Trash / Litter, Hazard / Wildlife, Other.
2. Confirm the spot — the pin drops at their current location. They can drag to correct if they're a few meters off. If they're not within roughly 50 meters of a known trail, the app tells them to move onto the trail before filing.
3. Photos — optional, up to 3 photos at 5 MB each.
4. Issue details — Title (optional), Description (optional), Your name (optional, defaults to Anonymous).

Submitting posts to POST /api/v1/public-report. On success the user sees a thank-you screen: Report submitted! "Thanks for keeping the trails safe. Your report has been sent to the {your-org-name} crew."

Offline case (weak signal at the trailhead) — the report is queued in the app's local storage and a "Saved — no connection right now" screen tells the user it'll upload automatically once their phone gets a signal.

Duplicate case (the trail user hit a "confirm existing" button on a report already known to your crew) — they see "Thanks for confirming! The {your-org-name} crew already knows about this one. Thanks for stopping to check — that's a real help."

The public report app also asks "Follow {your-org-name}?" after a successful submission — this is a native-app-only prompt that lets the reporter subscribe to your organization's push notifications for trail-condition changes. Useful for turning a one-off reporter into a returning informant.

Rate limiting and spam protection

Anonymous endpoints are honey for bots, so the report submission path has layered defenses:

• IP rate limit — 3 successful reports per 10-minute window per IP. Anything over that gets a 429 with the message "Too many reports from this address. Please try again later."
• Honeypot field — a hidden form field named website that real users leave blank. Any submission with that field filled gets a fake 200 response so bots don't retry.
• Client middleware — the endpoint requires a specific request header set by the TrailsIQ report app. Curl-based abuse without that header gets a 403.
• Photo caps — max 3 files, 5 MB each.
• Text caps — every text field is length-limited server-side.

There's no visible CAPTCHA on the report flow — the layered defense above has been enough. If spam rates ever spike, the admin panel has an audit log for public-report submissions per IP for investigation.

Moderating: approve or reject

Every public report lands as pending review. The pending-review count shows as a red badge on the Maintenance sidebar entry — that's the "someone needs to look at this" signal.

Open the Maintenance list, filter by Status → Pending review, and each row opens its Show page in the queue. Two moderation buttons live at the top of the page:

• Approve — flips the status to Open and adds the item to the main queue. Confirms with "Approve this report and move it to Open?" Success flash: "Approved and moved to open." Any bell notification about the pending-review submission is cleaned up so it doesn't linger.
• Reject — permanent delete. Confirms with "Reject and delete this report? This cannot be undone." The row disappears from the DB, its photos are trashed, and every notification referencing it is removed. Use this for spam, duplicates, or obviously-not-real reports.

Once approved, the item is a normal maintenance issue — set its priority, link it to a project, dispatch a crew, close it when done. Reject is destructive and doesn't leave a paper trail; be reasonably sure before hitting it.

The quick-status endpoints (the inline In progress / Resolved buttons on other maintenance items) refuse to work on pending-review items — the error surfaces as "Use approve or reject for pending-review items." The moderation flow is intentional, not a shortcut.

Notifications to your team

When a public report lands, TrailsIQ tries hard to make sure someone actually sees it.

• In-app bell notification — every active owner and manager gets a PendingReviewSubmitted bell entry. The dashboard's bell icon shows a red dot immediately.
• APNs push notification — sent to every owner / manager who has the TrailsIQ mobile app installed. Title: "Trail report needs review". Body: "{report title} · {trail name}".
• Email — sent via the PublicReportSubmitted mailable. Subject: "New trail report: {title}". Only sent to users who have New public trail reports enabled in their email preferences (default is enabled — see the Email preferences article for details).

If you find your inbox is loud, uncheck the email preference; you'll still get the in-app bell and the push notification.

Common gotchas

• Public reports are on by default for every organization. You opt out, not in. If you're deploying to a private landowner org that doesn't want public visibility, remember to flip the toggle.
• There is no per-org URL. Every organization shares app.trailsiq.com/report — the trail user picks the org from a "near me" list inside the app. Turning off the report toggle removes your org from that list.
• Rejecting a report is a hard delete. No soft-delete, no "hide from queue", no history. If in doubt, approve — you can always mark it as resolved without action later.
• A public report is always pending-review. Even if a logged-in owner tests the /report flow from their own account, the report lands as pending-review. The moderation gate is on the API, not the user identity.
• GPS is mandatory on the trail user's side. No manual "here's where I was" — the app refuses to send a report without a live GPS fix. This is deliberate: it kills the "someone reports from home about a trail they've never seen" spam.
• The email notification obeys the recipient's preferences. In-app bell + APNs push are always delivered; email is opt-out.

What's next

• If you want to reduce alert volume, turn off New public trail reports in your Email preferences — you'll still see everything on the bell and APNs. See the Email preferences article.
• Bulk-close old pending-review items? There's no bulk action today — each report needs an approve or reject decision on its Show page.
• Group approved reports into a project (e.g. "Storm cleanup 2026") so your rollup dashboard shows the whole cleanup as one thing. See Projects and work planning.