Surfaces
Reminders, Markdown, and Safe States
Support behavior for report reminders, markdown-ext fields, uploads, empty states, invalid IDs, unauthorized access, and expired sessions.
Use This Dashboard Area Safely
Use this guide when a safety, accountability, or follow-up record needs careful handling. In this guide, Reminders, Markdown, and Safe States narrows that work to support behavior for report reminders, markdown-ext fields, uploads, empty states, invalid IDs, unauthorized access, and expired sessions. Because this is a surfaces page, read it as part of the Report System learning path rather than as an isolated checklist.
A report is a written memory of something important. The goal is to protect people, keep facts clear, and leave enough context for future reviewers. Read the page for the decision it helps a person make, then use the steps and checks as a steady path from context to action to proof.
What The Screen Controls
This page explains a specific surface. Treat every button, field, filter, and table as a way to view or change real records, not just as a visual layout. The intended readers are Trust and Safety staff and Support leads. If the guide names a dashboard route, service area, export, or record type, treat that name as a pointer to real operational responsibility.
- Primary surface or service: /reports/manage?id=:incidentId, /reports/detail?id=:incidentId, and /reports/network-ban-appeal?entryId=:watchlistEntryId.
- Records or contracts involved: Reminder state, Markdown evidence, Upload context, and Error states.
- Main care point: Watch for incomplete facts, unfair wording, privacy exposure, or a decision that another reviewer cannot understand later.
- Proof worth keeping: report ID, saved status, revision history, person profile, evidence note, reminder, reviewer decision, and handoff owner.
Read The Screen From Top To Bottom
- Confirm you are on the right event, report, route, or file: Begin by naming the Report System situation, the owner, and the exact item involved in Reminders, Markdown, and Safe States.
- Read the current state before changing it: Use /reports/manage?id=:incidentId, /reports/detail?id=:incidentId, and /reports/network-ban-appeal?entryId=:watchlistEntryId to connect the words on the page to the screen, file, service route, or record that people actually use.
- Use the smallest action that matches the task: Keep Reminder state, Markdown evidence, Upload context, and Error states in view so the work stays tied to the records or contracts it can affect.
- Check the list, detail view, history, or public page afterward: Before handing off, save proof such as report ID, saved status, revision history, person profile, evidence note, reminder, reviewer decision, and handoff owner so another reviewer can understand the facts without relying on memory.
Before You Leave The Screen
You are ready to use the rest of this page when the purpose, owner, affected information, and proof are all clear enough for a second person to review.
- Scope is named: The work is tied to the correct page, event, report, route, file, person, or record.
- Impact is understood: The operator can explain the effect on people, privacy, fairness, evidence, and the trustworthiness of the record.
- Proof is findable: The handoff points to evidence that another reviewer can understand the facts without relying on memory.
End-to-end operator runbook
Use this numbered runbook when you need to operate this area without getting stuck. Read the purpose of each step, do the action in order, and use the final sentence as the checkpoint before continuing.
- Step 1 - Identify the report and scope. Open the report or reminder surface that needs work. This anchors the work to the correct scope before any record changes.
- Step 2 - Read the existing facts before acting. Check the current status, owner, reminder date, markdown field, uploads, and empty/error state. Pause here and confirm the note is factual, fair, and reviewable.
- Step 3 - Make the smallest factual update. Add or update reminder text with the exact next action and responsible person. This keeps the report useful to the next reviewer instead of only to the person writing it.
- Step 4 - Check fairness, privacy, and risk. Use markdown-ext for clarity, then preview or reread the rendered content. The next action should still protect privacy, evidence, and due process.
- Step 5 - Verify the saved record and history. Save and confirm the reminder appears in the expected list or report detail. A later reviewer should be able to understand this step from the saved record.
- Step 6 - Hand off the next responsibility. If uploads or state transitions fail, keep the error visible and escalate with the report ID. This leaves a handoff trail another operator can understand.
Report reminders
Report reminders help staff avoid forgotten follow-up. A reminder should be tied to a clear next action, such as checking evidence, contacting a reviewer, reviewing expiry, or closing a report.
Good reminder text:
- “Review witness statement by Friday.”
- “Check if temporary ban should expire after event.”
- “Follow up with FPH admin about cross-ban request.”
Bad reminder text:
- “Do this.”
- “Important.”
- “Ask around.”
Markdown-ext fields
Report text areas use the shared dashboard markdown-ext style for readable long-form notes. Use markdown for:
- Evidence inventories.
- Witness summaries.
- Timelines.
- Appeal process notes.
- Action explanations.
Upload context
Markdown evidence uploads should attach to the correct report context. On manage pages, the upload context depends on the report ID. If the page has no valid ID, uploads must not attach to the wrong report.
Safe empty and error states
The dashboard should explain what happened and what the user can do next.
| State | Safe behavior |
|---|---|
| Missing ID | Say the page needs a report or entry ID. |
| Invalid ID | Say the record could not be found or is not accessible. |
| Unauthorized | Explain access is not available for this role/scope. |
| Empty list | Explain whether no records exist or filters hide them. |
| Expired session | Redirect or request sign-in without showing stale sensitive data. |
| Failed save | Keep user input where possible and explain retry or escalation. |
Verification checklist
- Missing
?id=does not show the previous report. - Invalid
?id=gives a clear empty/error state. - Upload controls are disabled or safe without valid context.
- Expired auth does not leak report data.
- Reminder and markdown behavior survives refresh and navigation.