The admin pages Oolvay ships with provide basic operational tooling for managing users, reviewing platform activity, and monitoring application usage. All administrative routes live under /admin and are protected by role-based access controls.
Every administrative action is performed server-side and validated against the current user’s role before execution. Sensitive actions such as role changes, suspensions, and account deletion are recorded in the audit log.
| Route | File | Description |
|---|---|---|
/admin/overview | app/(protected)/admin/overview/page.tsx | Administrative dashboard and platform metrics |
/admin/users | app/(protected)/admin/users/page.tsx | User directory and account management |
/admin/users/[id] | app/(protected)/admin/users/[id]/page.tsx | Individual user profile and account details |
/admin/activity | app/(protected)/admin/activity/page.tsx | Platform audit log and event history |
/admin/system | app/(protected)/admin/system/page.tsx | Infrastructure diagnostics and deployment information |
The first three routes are available to both admin and super admin users. The System route is restricted to super admins and is intended for infrastructure monitoring and operational diagnostics.
The admin area uses a shared layout defined in app/(protected)/admin/layout.tsx.
Oolvay ships with three built-in roles.
| Role | Purpose |
|---|---|
| User | Standard application access |
| Admin | User management and operational oversight |
| Super admin | Full administrative access including infrastructure tooling |
0 / 2,000 characters
Super admin
└─ admin
└─ userEach level inherits the capabilities of the level beneath it.
| Capability | Admin | Super admin |
|---|---|---|
| View admin dashboard | ✓ | ✓ |
| View activity log | ✓ | ✓ |
| Search users | ✓ | ✓ |
| View user profiles | ✓ | ✓ |
| Change user roles | ✓ | ✓ |
| Suspend users | ✓ | ✓ |
| Unsuspend users | ✓ | ✓ |
| Delete users | ✓ | ✓ |
| Manage admins | ✗ | ✓ |
| Assign super admin role | ✗ | ✓ |
| Access system tools | ✗ | ✓ |
Administrative permissions are enforced through shared helpers in lib/auth/permissions.ts.
Administrative actions are recorded in the audit system for traceability and accountability.
The audit log stores both the user who performed an action and the user affected by that action.
| Field | Purpose |
|---|---|
actorUserId | User who performed the action |
targetUserId | User affected by the action |
event | Event identifier |
metadata | Structured event details |
createdAt | Event timestamp |
expiresAt | Retention expiration timestamp |
Examples of logged actions include role changes, account suspension, account restoration, user deletion, sign-ins, sign-outs, and other security-related events.
Most administrative actions follow the same lifecycle.
This pattern is used throughout user management, role assignment, account suspension, and account deletion workflows.