# Admin Dashboard User Flagging and Unusual Activity Monitoring in prompts.chat

> Explore user flagging and unusual activity monitoring in the prompts.chat admin dashboard. Real-time filtering and audit trails empower administrators to maintain platform integrity.

- Repository: [Fatih Kadir Akın/prompts.chat](https://github.com/f/prompts.chat)
- Tags: how-to-guide
- Published: 2026-04-02

---

**The prompts.chat admin dashboard provides a complete user moderation system that allows administrators to flag accounts exhibiting unusual activity, filter suspicious users in real-time, and maintain full audit trails with timestamped records and reason codes.**

The open-source prompts.chat repository implements a robust admin interface built with Next.js, TypeScript, and Prisma. Understanding how the admin dashboard handles user flagged status and unusual activity monitoring is essential for maintaining community safety and compliance.

## How User Flagging Works in the Admin Dashboard

The moderation workflow centers on the `UsersTable` component in [`src/components/admin/users-table.tsx`](https://github.com/f/prompts.chat/blob/main/src/components/admin/users-table.tsx), which renders a searchable, filterable interface for managing user accounts.

### The Users Table Interface

The client-side table displays a warning icon (⚠️) next to any user where `flagged: true` in the database. Administrators can trigger actions through a dropdown menu on each row that exposes options to **flag**, **un-flag**, change roles, verify emails, edit credit limits, or delete accounts.

When an admin selects the flag option, the `handleFlagToggle` function executes a **PATCH** request to the admin API:

```tsx
const handleFlagToggle = async (userId: string, flagged: boolean) => {
  const res = await fetch(`/api/admin/users/${userId}`, {
    method: "PATCH",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      flagged,
      flaggedReason: flagged ? "Unusual activity" : null,
    }),
  });
  if (res.ok) toast.success(flagged ? t("flagged") : t("unflagged"));
};

```

The UI immediately reflects state changes by re-fetching the current page data, ensuring real-time feedback without requiring a full page reload.

### Privacy and Transparency

According to [`src/app/privacy/page.tsx`](https://github.com/f/prompts.chat/blob/main/src/app/privacy/page.tsx), the platform discloses to end users that flagged status may be applied when "unusual activity" is detected, maintaining transparency about automated and manual moderation actions.

## API Implementation for Flagged Status Management

The server-side logic enforces strict role-based access control before processing any flag state modifications.

### Server-Side Role Verification

All admin endpoints in [`src/app/api/admin/users/route.ts`](https://github.com/f/prompts.chat/blob/main/src/app/api/admin/users/route.ts) validate the session via the `auth()` helper from `src/lib/auth`. The system immediately rejects requests where `session.user.role !== "ADMIN"`, ensuring only authorized personnel can view or modify sensitive user metadata.

The GET endpoint supports pagination, search, and filtering through query parameters:

```ts
const params = new URLSearchParams({
  page: page.toString(),
  limit: "15",
  ...(search && { search }),
  ...(filter !== "all" && { filter }),
});
const res = await fetch(`/api/admin/users?${params}`);

```

When `filter=flagged` is passed, the API constructs a Prisma `where` clause matching `flagged: true` to return only flagged accounts.

### PATCH Endpoint for Status Updates

Individual user updates route through `src/app/api/admin/users/[userId]/route.ts`. After verifying admin privileges, the endpoint updates the user record and automatically manages audit timestamps:

```ts
await db.user.update({
  where: { id: userId },
  data: {
    flagged,
    flaggedReason,
    flaggedAt: flagged ? new Date() : null,
  },
});

```

The `flaggedAt` field records the exact timestamp of the action, creating an immutable audit trail for compliance review.

## Database Schema for Audit Trails

The Prisma schema in `prisma/schema.prisma` defines the data model supporting the flagging system:

```prisma
model User {
  id                     String   @id @default(uuid())
  email                  String   @unique
  username               String   @unique
  flagged                Boolean  @default(false)
  flaggedAt              DateTime?
  flaggedReason          String?
  // ... additional fields
}

```

This design separates the boolean state (`flagged`) from contextual metadata (`flaggedAt`, `flaggedReason`), allowing administrators to understand not just *whether* an account was flagged, but *when* and *why*.

## Filtering and Monitoring Unusual Activity

The admin dashboard provides dedicated tools for identifying patterns across the user base.

### Query Parameters and Filtering Logic

The filter dropdown in [`src/components/admin/users-table.tsx`](https://github.com/f/prompts.chat/blob/main/src/components/admin/users-table.tsx) includes a **"Flagged"** option that appends `filter=flagged` to the query string. When the filter changes, a `useEffect` hook triggers `fetchUsers` to retrieve the filtered dataset:

```tsx
useEffect(() => {
  fetchUsers(currentPage, searchQuery, userFilter);
}, [currentPage, userFilter, fetchUsers]);

```

On the server, the route handler inspects the `filter` parameter and builds dynamic Prisma queries. This allows administrators to quickly isolate accounts requiring review without scrolling through thousands of legitimate users.

## Summary

- **Role-based security**: All flagging operations require the **ADMIN** role, verified in [`src/app/api/admin/users/route.ts`](https://github.com/f/prompts.chat/blob/main/src/app/api/admin/users/route.ts) and the PATCH endpoint.
- **Real-time UI**: The `UsersTable` component provides instant feedback through React state management and toast notifications.
- **Audit trail**: The Prisma schema stores `flagged`, `flaggedAt`, and `flaggedReason` to create a complete history of moderation actions.
- **Filterable views**: Administrators can view all users or isolate only flagged accounts using the `filter=flagged` query parameter.
- **Transparency**: The privacy page discloses the flagging policy to end users, documenting what constitutes "unusual activity".

## Frequently Asked Questions

### How does the flagging system detect unusual activity?

The system relies on administrator observation rather than automated detection. When an admin identifies suspicious behavior patterns—such as rapid-fire prompt generation, credit abuse, or content policy violations—they manually trigger the flag via the dashboard. The default reason code "Unusual activity" is applied, though custom reasons can be stored in the `flaggedReason` field.

### What permissions are required to flag users?

Only users with the **ADMIN** role can flag or unflag accounts. The `auth()` session helper validates this role in both the GET and PATCH handlers within `src/app/api/admin/users/`. Attempts to access these endpoints without proper credentials return a 403 Forbidden response before any database operations occur.

### Can flagged users see their status on the platform?

The privacy policy in [`src/app/privacy/page.tsx`](https://github.com/f/prompts.chat/blob/main/src/app/privacy/page.tsx) informs users that flagged status may be applied for unusual activity, but the dashboard itself does not expose the flag state to the flagged user's profile view. The status is internal to the moderation team, though the platform may impose functional restrictions (such as rate limiting or feature disablement) based on the flag in other parts of the application.

### Is the flagging history preserved after unflagging?

While the `flagged` boolean resets to `false` when unflagged, the schema design preserves the history partially. Setting `flagged: false` clears the `flaggedAt` and `flaggedReason` fields by setting them to `null` according to the PATCH endpoint logic. For permanent audit trails, you would need to extend the schema with a separate `FlagHistory` model or logging table.