Content Moderation & Media Review System

User-generated content moderation pipeline — pre-publication review, community reporting, admin tools, and server-side enforcement.

1. Overview

All user-uploaded media (photos attached to wildlife sightings) passes through a mandatory moderation pipeline before becoming visible to the community. No public media is displayed without explicit admin approval.

2. Pre-Publication Review

Every public media upload enters the system in a pending state (ReviewStatus = 0). Media is not visible to any other user until an admin explicitly approves it.

Visibility rule (enforced in client code and backend database security rules):

visible = (ReviewStatus == approved) AND (Private == 0) AND (Deleted == 0)

• Users see their own uploads immediately (local device only) with upload progress indicators.
• Other users never see pending, rejected, or removed content.
• Private media (e.g. personal trip check-in photos) bypasses the review queue entirely and is only visible to the owner.

3. Review Status Lifecycle

Media progresses through a strict state machine with five states:

State transitions:

Upload created
    |
    v
PENDING (0)
    |
    +---> APPROVED (1) -----> [community reports] ----> UNDER REVIEW (3)
    |                                                        |
    +---> REJECTED (2)                         +-------------+-------------+
                                               |                           |
                                          RE-APPROVED (1)       PERMANENTLY REMOVED (4)
                                                                    [terminal]

4. Admin Review Dashboard

Administrators access a dedicated moderation interface with four tabs:

4.1 New Submissions

• Displays all media with ReviewStatus = pending (0) that has been uploaded and is public.
• Sorted newest-first, limited to 50 items per page.
• Actions: Approve, Approve as Graphic, Reject, Delete.

4.2 Reported Content

• Displays approved media that has received one or more community reports (ReportCount > 0).
• Sorted by report count (highest first) to prioritise the most-reported items.
• Shows a report summary with category breakdown (Graphic / Irrelevant / Offensive).
• Actions: Flag as Graphic, Remove, Dismiss Reports.

4.3 Re-Review Queue

• Displays media automatically escalated to ReviewStatus = Under Review (3) when report counts exceed a threshold.
• Actions: Re-approve, Re-approve as Graphic, Permanently Remove.

4.4 Moderation Summary

• Aggregated moderation statistics per user.
• Shows users with the most reported media and users who have filed the most reports.
• Supports sorting to identify patterns of misuse.

5. Community Reporting

Any authenticated user can report media they find objectionable.

Report Categories

Safeguards

• One report per user per media item: Enforced by the Firestore document ID pattern ({reporterUserId}_{mediaId}). Duplicate reports from the same user are structurally impossible.
• Admin-only category: A fourth category (adminAction, value 3) exists for internal audit entries. Community users cannot create reports with this category — enforced by Firestore security rules.
• Optional description: Users may provide up to 200 characters of additional context.
• Non-blocking UX: Report submission is fire-and-forget. The form closes immediately with a confirmation toast, ensuring the reporting mechanism is frictionless while preventing abuse through the one-report-per-user constraint.

6. Graphic Content Handling

Rather than removing content that is graphic but legitimate (e.g. wildlife predation scenes), the system supports a graphic content flag:

• When an admin flags media as graphic (Graphic = 1), the content remains in the feed but is displayed with a blur overlay.
• The overlay shows a warning label and a "Tap to view" prompt.
• Revealing the image is a client-side UI state change only — no data is written to the server, and the content re-blurs when the user navigates away.
• This approach allows nature photography that some users may find sensitive to remain available without being displayed unexpectedly.

7. Server-Side Enforcement (Firestore Security Rules)

Moderation integrity is enforced at the database level, not just in client code.

Media Documents

Media Reports

Firebase Storage

8. Admin Audit Trail

Every admin action on media creates a permanent audit record:

• Document type: A MediaReport with category = adminAction (3).
• Document ID pattern: {adminUserId}_{mediaId}_{timestamp} — allows multiple admin actions on the same media item to be recorded.
• Fields recorded: Admin user ID, timestamp, outcome (re-approved / removed / graphic-flagged), and an optional admin note.
• Immutability: Community users cannot create adminAction reports (enforced by security rules). Existing reports are never deleted.

When an admin resolves reported content, all pending community reports for that media item are batch-updated with the admin's outcome, user ID, and timestamp.

9. Report Resolution Flow

When an admin acts on reported content, the following occurs in a single batch operation:

1. The media item's ReviewStatus and/or Graphic flag is updated.
2. All pending community reports for that media are updated with:
   • AdminOutcome (re-approved / removed / graphic-flagged)
   • AdminUserID (which admin acted)
   • AdminTimestamp (when the action was taken)
3. An audit trail entry (adminAction report) is created.
4. Local caches are invalidated so the feed reflects the decision immediately.

10. Summary of Moderation Safeguards