User Management

​

Access Requirements

​

User List View

• Statistics cards: Total users, hidden count, banned count, and elevated roles (admins/moderators)
• Search: Filter by display name or username (case-insensitive)
• Tab filters: All, Active, Hidden, Banned
• Pagination: 20 users per page

• Avatar and display name (obfuscated for privacy)
• Username (if set)
• Clerk ID (obfuscated, click to reveal)
• Role badge (user, moderator, or admin)
• Status badge (Active, Hidden, or Banned)
• Country code and account age
• Quick action buttons

​

Privacy Features

​

User Detail View

​

Profile Information

• Display name, username, Clerk ID
• Country and region (ISO codes)
• Experience level
• Bio and social links (GitHub, Twitter, website, Twitch)
• Account creation date

​

Moderation History

• Action timestamp
• Name of admin/moderator who performed the action
• Ban reason (if provided)

​

Activity

• Event Registrations: Shows registered events with team preference and commitment level
• Projects: Lists all projects created by the user (with links if slug exists)

​

Moderation Actions

​

Hide User

hideUser({ profileId: string })

• Sets hiddenAt timestamp and hiddenBy actor ID
• User can still sign in but profile is filtered from public queries
• Cannot hide super-admins (defined in ADMIN_USER_IDS env var)
• Logs action to adminAuditLog table

• Cannot hide users who are already hidden
• Cannot hide super-admins

​

Unhide User

unhideUser({ profileId: string })

• Clears hiddenAt and hiddenBy fields
• Restores profile to public queries
• Logs action to audit log

​

Ban User

banUser({ profileId: string, reason?: string })

• Sets bannedAt, bannedBy, and optional banReason
• Calls clerk.users.banUser(clerkId) to disable authentication
• Banned users are redirected to /banned page by middleware
• Logs action with reason to audit log

• Cannot ban super-admins
• Cannot ban yourself
• Cannot ban already-banned users

​

Unban User

unbanUser({ profileId: string })

• Clears bannedAt, bannedBy, banReason, hiddenAt, and hiddenBy
• Calls clerk.users.unbanUser(clerkId) to restore authentication
• Logs action to audit log

​

Delete User

1. Team invites (sent and received)
2. Project memberships
3. Event registrations
4. Event projects
5. Projects (owned)
6. Profile record

• Logs to audit log with deleted user metadata (since target profile no longer exists)
• Calls clerk.users.deleteUser(clerkId) to remove from Clerk

• Cannot delete super-admins
• Cannot delete yourself

​

Implementation Details

​

Database Schema

{
  id: uuid,
  clerkId: text (unique),
  username: text (unique, nullable),
  displayName: text,
  role: userRoleEnum, // user | moderator | admin
  bannedAt: timestamp (nullable),
  bannedBy: uuid (nullable, FK to profiles),
  banReason: text (nullable),
  hiddenAt: timestamp (nullable),
  hiddenBy: uuid (nullable, FK to profiles),
  createdAt: timestamp
}

​

Server Actions

• hideUser (lines 36-74)
• unhideUser (lines 76-111)
• banUser (lines 113-182)
• unbanUser (lines 184-237)
• deleteUser (lines 239-309)

1. Verifies actor permissions via isModerator(userId) or isAdmin(userId)
2. Validates target user state and super-admin checks
3. Performs database updates
4. Syncs with Clerk (non-blocking — DB is source of truth)
5. Logs to adminAuditLog
6. Revalidates /admin/users path
7. Returns { success: true } or { success: false, error: string }

​

Queries

• getAdminUserList() (lines 144-163): Returns all profiles ordered by creation date
• getAdminUserDetail(profileId) (lines 165-204): Returns profile with relations (projects, registrations) and moderator names
• getAdminUserStats() (lines 241-265): Returns counts for total, hidden, banned, and elevated users

​

Client Components

• Client-side search and filtering state
• Obfuscated field rendering for PII protection
• Action buttons conditional on user status and current role
• Real-time role badge and status indicators

• Renders action buttons based on current moderation state
• Shows unban button only to admins
• Confirmation dialogs for destructive actions

​

Role Permissions Matrix

​

Best Practices

1. Always provide a ban reason to document moderation decisions
2. Use hide instead of ban for temporary visibility restrictions
3. Check audit log before reversing another moderator’s actions
4. Verify super-admin status before attempting admin-level actions (system will prevent, but awareness helps)
5. Review user activity (registrations, projects) before deletion to assess impact