System Administration

Relevant source files

• frontend/src/App.jsx
• frontend/src/AuthContext.jsx
• frontend/src/components/SettingsSidebar/index.jsx
• frontend/src/models/system.js
• frontend/src/utils/paths.js
• server/endpoints/admin.js
• server/endpoints/api/admin/index.js
• server/endpoints/system.js

System Administration encompasses all functions related to managing users, authentication, workspace access control, audit logging, and system-wide settings in AnythingLLM. This includes both single-user and multi-user deployment modes, with robust role-based access control (RBAC) in multi-user environments.

For LLM provider configuration and vector database settings, see Configuration Management. For workspace-specific settings and document management, see Workspace Management.

Authentication Modes and Token Management

AnythingLLM supports four authentication modes with distinct token management strategies. The mode is determined by checking SystemSettings.isMultiUserMode() in middleware.

Authentication Mode Diagram

Sources: server/endpoints/system.js183-334 server/endpoints/system.js336-377 server/utils/http.js

<old_str>

Multi-User Mode

Multi-user mode is enabled via POST /system/enable-multi-user at server/endpoints/system.js591-644 This endpoint:

1. Checks if already enabled via response.locals.multiUserMode at line 596
2. Creates first admin user via User.create({ username, password, role: ROLES.admin }) at lines 604-609
3. Calls SystemSettings._updateSettings({ multi_user_mode: true }) at line 619
4. Migrates browser extension API keys at line 622
5. Sets JWT secret via updateENV() at lines 624-629

The login flow at server/endpoints/system.js183-334 performs:

1. Checks if Simple SSO is disabled via simpleSSOLoginDisabled() at line 188
2. Username lookup via User._get({ username: String(username) }) at line 200
3. Password verification using bcrypt.compareSync(String(password), existingUser.password) at line 220
4. Suspension check via if (existingUser.suspended) at line 238
5. JWT generation via makeJWT({ id: existingUser.id, username: existingUser.username }, process.env.JWT_EXPIRY) at lines 273-276
6. Optional recovery code generation for first login via generateRecoveryCodes(existingUser.id) at line 278

Event logging for failed attempts:

• failed_login_invalid_username at lines 203-210
• failed_login_invalid_password at lines 222-235
• failed_login_account_suspended at lines 239-253

Sources: server/endpoints/system.js183-334 server/endpoints/system.js591-644 server/models/user.js </old_str>

<new_str>

Single-User Mode

In single-user mode, authentication relies on the AUTH_TOKEN environment variable. The login flow at server/endpoints/system.js296-329 performs:

1. Extracts password from request body via reqBody(request) at line 297
2. Compares using bcrypt.compareSync(password, bcrypt.hashSync(process.env.AUTH_TOKEN, 10)) at lines 299-301
3. Logs failed attempts via EventLogs.logEvent("failed_login_invalid_password") at line 304
4. On success, generates JWT via makeJWT() at lines 323-326 with encrypted payload:

The EncryptionManager class at server/utils/EncryptionManager.js encrypts the password to prevent plaintext storage in the JWT.

Sources: server/endpoints/system.js296-329 server/utils/EncryptionManager.js

Single-User Mode

In single-user mode, authentication relies on a password stored in the AUTH_TOKEN environment variable. The login flow at server/endpoints/system.js230-263 compares the submitted password against the hashed AUTH_TOKEN. On successful authentication, a JWT token is generated containing an encrypted password payload using the EncryptionManager class.

The JWT is created via makeJWT() at server/endpoints/system.js257-260 with a payload structure:

Simple SSO

Simple SSO provides token-based authentication via GET /request-token/sso/simple at server/endpoints/system.js336-377 The flow:

1. External system creates a record in temporary_auth_tokens table
2. User navigates to frontend route with query param: /sso/simple?token=<tempToken>
3. Frontend calls backend endpoint with token in query string at line 340
4. Backend validates via TemporaryAuthToken.validate(tempAuthToken) at lines 341-342, which:
   • Checks token exists and is not expired
   • Retrieves associated user from users table
   • Marks token as consumed
5. Returns session JWT via standard makeJWT() at line 373
6. Logs login event at lines 361-368

The simpleSSOEnabled middleware at line 338 enforces SSO is enabled. Login via credentials can be blocked using simpleSSOLoginDisabledMiddleware which is applied to invite creation at server/endpoints/admin.js177

Sources: server/endpoints/system.js336-377 server/models/temporaryAuthToken.js server/utils/middleware/simpleSSOEnabled.js

API Key Authentication

API keys provide programmatic access without session management. The validApiKey middleware at server/utils/middleware/validApiKey.js validates keys for /v1/* API routes by:

1. Extracting bearer token from Authorization header
2. Querying api_keys table via ApiKey.get({ secret: apiKey })
3. In multi-user mode, loading associated user and attaching to response.locals.user
4. Returning 403 if invalid or missing

In multi-user mode, API keys are created with createdByUserId foreign key linking to the users table. In single-user mode, the createdByUserId field is null.

Sources: server/utils/middleware/validApiKey.js server/models/apiKeys.js

Role-Based Access Control (RBAC)

RBAC Architecture Diagram

Sources: server/utils/middleware/multiUserProtected.js39-158 server/utils/helpers/admin.js server/endpoints/admin.js35-497

Role Hierarchy

Three roles are defined in the ROLES constant at server/utils/middleware/multiUserProtected.js39-42:

Role	Database Value	Permissions
admin	"admin"	Full system access: LLM/vector DB config, all user/workspace operations, system settings
manager	"manager"	User and workspace management, invite creation, workspace chat viewing, security/branding settings
default	"default"	Workspace access controlled via workspace_users table, can update own profile

The all pseudo-role matches any authenticated user and is used for endpoints like profile picture upload.

Sources: server/utils/middleware/multiUserProtected.js39-42

Middleware Enforcement

Two primary middleware functions enforce role-based access:

strictMultiUserRoleValid([roles]) at server/utils/middleware/multiUserProtected.js125-158

• Line 128-132: Checks if multi-user mode enabled via isMultiUserSetup(response)
• Line 135-137: Retrieves user via userFromSession(request, response)
• Line 142-150: Validates role membership via flexUserRoleValid([roles])(request, response, next)
• Returns 401 if multi-user mode disabled
• Used for admin/manager endpoints: /admin/users, /admin/invites, /admin/workspaces

flexUserRoleValid([roles]) at server/utils/middleware/multiUserProtected.js88-123

• Line 91-95: If single-user mode (!multiUserMode(response)), allows all access
• Line 97-99: Retrieves user via userFromSession(request, response)
• Line 105-116: Checks if user's role in allowed roles array or if ROLES.all specified
• Returns 403 if role check fails
• Used for endpoints that work in both modes: /system/update-env, /system/event-logs, /system/pfp/:id

Sources: server/utils/middleware/multiUserProtected.js88-158

Authorization Helpers

The admin helper functions at server/utils/helpers/admin.js provide fine-grained authorization logic called by endpoints before user modifications:

validRoleSelection(currentUser, newUserData)

• Purpose: Prevents managers from creating/modifying admin users
• Implementation: Checks if currentUser.role === "manager" and newUserData.role === "admin"
• Returns: { valid: boolean, error: string }
• Usage: Called at server/endpoints/admin.js56 in POST /admin/users/new and line 101 in POST /admin/user/:id

canModifyAdmin(targetUser, updates)

• Purpose: Prevents demoting/suspending the last active admin
• Implementation:
  • Counts total active admins in users table via User.count({ role: "admin", suspended: 0 })
  • If only one admin exists and target is that admin, blocks role change or suspension
• Returns: { valid: boolean, error: string }
• Usage: Called at server/endpoints/admin.js109 before User.update() in POST /admin/user/:id

validCanModify(currentUser, targetUser)

• Purpose: Prevents managers from modifying higher-privilege users (admins)
• Implementation: Returns false if currentUser.role === "manager" and targetUser.role === "admin"
• Returns: { valid: boolean, error: string }
• Usage: Called at server/endpoints/admin.js95 in POST /admin/user/:id and line 135 in DELETE /admin/user/:id

Sources: server/utils/helpers/admin.js server/endpoints/admin.js49-156

User Management Operations

User Management Flow Diagram

Sources: server/endpoints/admin.js49-124

User Management Operations

User Management Flow Diagram

Sources: server/endpoints/admin.js35-156

Creating Users

User creation is handled by the /admin/users/new endpoint at server/endpoints/admin.js49-83 The flow:

1. Extract current user via userFromSession() at server/endpoints/admin.js54
2. Validate role assignment via validRoleSelection() at server/endpoints/admin.js56
3. Call User.create(newUserParams) at server/endpoints/admin.js65
4. Log creation event at server/endpoints/admin.js67-75

Required fields for user creation:

• username - String, validated by User.validations.username()
• password - String, hashed with bcrypt before storage
• role - One of: admin, manager, default

Optional fields:

• suspended - Boolean, defaults to 0 (false)

The User.create() method at server/models/user.js performs:

• Username validation and uniqueness check
• Password hashing using bcrypt with 10 salt rounds
• Database insertion into users table
• Returns { user, error } with filtered user data

Updating Users

User updates via POST /admin/user/:id at server/endpoints/admin.js85-124 perform three authorization checks:

1. Line 95: validCanModify(currUser, user) - Ensures current user can modify target user (managers cannot modify admins)
2. Line 101: validRoleSelection(currUser, updates) - Validates role change is permitted (managers cannot assign admin role)
3. Line 109: canModifyAdmin(user, updates) - Prevents demoting/suspending last admin

Each check returns { valid: boolean, error: string }. If any check fails, the endpoint returns 200 { success: false, error } without modifying the user.

Example Update Payload:

All fields are optional. The User.update(id, updates) method at line 117:

• Only modifies provided fields
• Hashes password if provided
• Updates users table record
• Returns { success: boolean, error: string | null }

Sources: server/endpoints/admin.js85-124 server/models/user.js

Deleting Users

User deletion via DELETE /admin/user/:id at server/endpoints/admin.js126-156 performs:

1. Line 133: Retrieve user via User.get({ id: Number(id) }) from users table
2. Line 135: Validate modification permission via validCanModify(currUser, user)
3. Line 141: Delete user via User.delete({ id: Number(id) })
4. Lines 142-149: Log deletion event:

The User.delete() method cascades to related records:

• Removes entries from workspace_users table (workspace access)
• Removes entries from api_keys table (API keys created by user)
• Removes entries from invites table (invites created by user)
• Does not delete chat history (preserves data integrity)

Sources: server/endpoints/admin.js126-156 server/models/user.js

User Self-Service

Users can update their own profile via POST /system/user (referenced in frontend/src/models/system.js680-691) without admin permissions. This endpoint:

• Requires only validatedRequest middleware (no role check)
• Retrieves user via userFromSession(request, response)
• Allows updates to: username, password, bio, pfpFilename
• Calls User.update(user.id, data) with provided fields

Users can also upload/remove profile pictures via:

• POST /system/upload-pfp at server/endpoints/system.js764-802 with handlePfpUpload multer middleware
• DELETE /system/remove-pfp at server/endpoints/system.js855-889

Sources: server/endpoints/system.js764-889 frontend/src/models/system.js680-691 server/models/user.js

Workspace Administration

Workspace Access Control Diagram

Sources: server/endpoints/admin.js224-320 server/endpoints/api/admin/index.js425-660

Listing Workspaces with Users

The /admin/workspaces endpoint at server/endpoints/admin.js224-236 returns all workspaces with their associated users via Workspace.whereWithUsers(). This method joins the workspaces, workspace_users, and users tables to return:

Retrieving Workspace Users

The /admin/workspaces/:workspaceId/users endpoint at server/endpoints/admin.js238-251 calls Workspace.workspaceUsers(workspaceId) which queries the workspace_users join table to return user associations for a specific workspace.

Creating Workspaces

Workspace creation at server/endpoints/admin.js253-270 uses Workspace.new(name, userId) which:

1. Generates a unique slug from the workspace name
2. Creates the workspace record
3. Associates the creator as an initial user
4. Returns { workspace, message }

Managing Workspace Access

Two methods control workspace access:

Workspace.updateUsers(workspaceId, userIds) at server/endpoints/admin.js272-289

• Overwrites all workspace user associations
• Deletes existing workspace_users records for the workspace
• Creates new records for the provided user IDs
• Used by deprecated /admin/workspaces/:id/update-users endpoint

WorkspaceUser.createManyUsers(userIds, workspaceId)

• Adds users to a workspace without removing existing users
• Used by the newer /v1/admin/workspaces/:slug/manage-users endpoint at server/endpoints/api/admin/index.js547-660

The API endpoint supports two modes via the reset parameter:

• reset: true - Calls updateUsers() to replace all users
• reset: false - Adds new users via createManyUsers() without removing existing users

Deleting Workspaces

Workspace deletion at server/endpoints/admin.js291-320 cascades to all related data:

1. Delete workspace chats via WorkspaceChats.delete({ workspaceId })
2. Delete document vectors via DocumentVectors.deleteForWorkspace()
3. Delete document records via Document.delete({ workspaceId })
4. Delete workspace record via Workspace.delete({ id })
5. Delete vector namespace via VectorDb<FileRef file-url="https://github.com/Mintplex-Labs/anything-llm/blob/eaa35eba/\"delete-namespace\"" undefined file-path="\"delete-namespace\"">Hii</FileRef>

This ensures complete cleanup of all workspace-related data including chat history, embeddings, and vector storage.

Sources: server/endpoints/admin.js224-320 server/endpoints/api/admin/index.js425-660 server/models/workspace.js server/models/workspaceUsers.js

Invite System

Invite System Architecture

Sources: server/endpoints/admin.js158-222 server/models/invite.js

Creating Invites

Invite creation occurs via /admin/invite/new at server/endpoints/admin.js172-202 The endpoint:

1. Requires ROLES.admin or ROLES.manager permission
2. Blocked if Simple SSO login is disabled via simpleSSOLoginDisabledMiddleware at server/endpoints/admin.js177
3. Accepts optional workspaceIds array in request body
4. Calls Invite.create() at server/endpoints/admin.js183-186
5. Logs creation event at server/endpoints/admin.js188-195

The Invite.create() method:

• Generates a unique invite code using UUID
• Creates invite record with status: 'pending'
• Associates creator via createdByUserId
• Creates invite_workspace records for pre-assigned workspaces
• Returns { invite, error }

Example request payload:

Listing Invites

The /admin/invites endpoint at server/endpoints/admin.js158-170 returns all invites with user information via Invite.whereWithUsers(). This joins invites with creator and claimer user records to return:

Deactivating Invites

Invite deactivation via /admin/invite/:id at server/endpoints/admin.js204-222 calls Invite.deactivate(id) which:

• Sets invite status to 'disabled'
• Does not delete the record (soft delete)
• Preserves audit trail of who created the invite

This is logged via EventLogs.logEvent("invite_deleted") at server/endpoints/admin.js211-215

Accepting Invites

When a user accepts an invite through the /accept-invite/:code page (frontend route at frontend/src/App.jsx133-135), the backend:

1. Validates the invite code exists and has status: 'pending'
2. Creates a new user account with the provided credentials
3. Updates invite status to 'accepted' and sets claimedByUserId
4. Associates user with pre-assigned workspaces from invite_workspace table
5. Returns session token for immediate login

Sources: server/endpoints/admin.js158-222 server/models/invite.js server/utils/middleware/simpleSSOEnabled.js

Event Logging and Telemetry

Event Logging System Diagram

Sources: server/models/eventLogs.js server/models/telemetry.js server/endpoints/system.js1040-1077

EventLogs Model

The EventLogs model at server/models/eventLogs.js provides system-wide audit logging. Key methods:

EventLogs.logEvent(event, metadata, userId) Creates a log entry with:

• event - String event type (e.g., "user_created")
• metadata - JSON object with event-specific data
• userId - Optional user ID who triggered the event
• occurredAt - Automatic timestamp

Example usage at server/endpoints/admin.js67-75:

EventLogs.whereWithData(conditions, limit, offset, orderBy) Retrieves paginated logs with user information joined from the users table. Called by /system/event-logs endpoint at server/endpoints/system.js1040-1058

EventLogs.count() Returns total log count for pagination calculations.

EventLogs.delete() Clears all event logs. Used by /system/event-logs DELETE endpoint at server/endpoints/system.js1060-1077 The deletion itself is logged as an "event_logs_cleared" event.

Event Types

Common event types logged throughout the system:

Event Type	Triggered By	Metadata
login_event	Successful login	{ ip, username, multiUserMode }
failed_login_invalid_username	Bad username	{ ip, username }
failed_login_invalid_password	Bad password	{ ip, username }
failed_login_account_suspended	Suspended account	{ ip, username }
user_created	Admin creates user	{ userName, createdBy }
user_deleted	Admin deletes user	{ userName, deletedBy }
invite_created	Admin creates invite	{ inviteCode, createdBy }
invite_deleted	Admin deactivates invite	{ deletedBy }
api_key_created	API key generation	{ createdBy }
api_key_deleted	API key deletion	{ deletedBy }
multi_user_mode_enabled	Multi-user activation	{}
exported_chats	Chat export	{ type, chatType }
event_logs_cleared	Event log deletion	{}

Telemetry System

The Telemetry model at server/models/telemetry.js sends anonymous usage statistics to Mintplex Labs. Key characteristics:

Telemetry.sendTelemetry(event, properties, userId)

• Sends events to external telemetry service
• Disabled if DISABLE_TELEMETRY=true environment variable is set
• Includes anonymous instance ID
• Never sends sensitive data (passwords, API keys, chat content)

Telemetry is sent for high-level events like:

• Login events at server/endpoints/system.js190-194
• Multi-user mode enablement at server/endpoints/system.js564-566

Users can disable telemetry entirely via the Privacy settings UI or by setting DISABLE_TELEMETRY=true.

Viewing Event Logs

The admin UI displays event logs at the /settings/event-logs page (route at frontend/src/App.jsx197-199). The frontend fetches logs via:

This calls the /system/event-logs endpoint at server/endpoints/system.js1040-1058 which returns:

Administrators can clear all logs via the UI, which calls System.clearEventLogs() at frontend/src/models/system.js600-610

Sources: server/models/eventLogs.js server/models/telemetry.js server/endpoints/system.js1040-1077 frontend/src/models/system.js576-610

API Key Management

API Key System Architecture

Sources: server/endpoints/system.js943-1016 server/endpoints/admin.js496-559 server/models/apiKeys.js server/models/browserExtensionApiKey.js

System API Keys

System API keys provide programmatic access to the /v1/* API endpoints. The system supports different endpoint groups based on authentication mode:

Single-User Mode (endpoints at server/endpoints/system.js943-1016)

• /system/api-keys GET - Lists all API keys
• /system/generate-api-key POST - Creates new API key
• /system/api-key/:id DELETE - Deletes specific key
• All endpoints blocked in multi-user mode via multiUserMode() check at server/endpoints/system.js945-947

Multi-User Mode (endpoints at server/endpoints/admin.js496-559)

• /admin/api-keys GET - Lists all keys with user associations via ApiKey.whereWithUser({}) at server/endpoints/admin.js501
• /admin/generate-api-key POST - Creates key associated with current user at server/endpoints/admin.js522
• /admin/delete-api-key/:id DELETE - Removes key with event logging at server/endpoints/admin.js546
• All endpoints require ROLES.admin role via strictMultiUserRoleValid middleware

API Key Creation

When creating an API key via ApiKey.create():

Single-User Mode:

Multi-User Mode:

The secret is a cryptographically random string generated using the crypto module. It's shown only once upon creation and cannot be retrieved later.

All API key operations are logged via EventLogs.logEvent():

• Creation: "api_key_created" at server/endpoints/system.js973-977
• Deletion: "api_key_deleted" at server/endpoints/system.js1005-1009

validApiKey Middleware

The validApiKey middleware at server/utils/middleware/validApiKey.js validates API keys for programmatic endpoints:

1. Extracts bearer token from Authorization header
2. Queries ApiKey model for matching secret
3. In multi-user mode, attaches user information to response.locals
4. Returns 403 if invalid or missing

This middleware protects all /v1/* API routes including:

• /v1/workspace/* - Workspace operations
• /v1/admin/* - Administrative functions
• /v1/document/* - Document management

Browser Extension API Keys

Browser extension keys use a separate model BrowserExtensionApiKey with additional features:

• Workspace Restrictions: Keys can be limited to specific workspace IDs via the workspaceIds JSON field
• User Association: In multi-user mode, keys are tied to specific users
• Migration: When enabling multi-user mode, existing browser extension keys are migrated via BrowserExtensionApiKey.migrateApiKeysToMultiUser() at server/endpoints/system.js556

Browser extension keys are managed through the /settings/browser-extension UI (route at frontend/src/App.jsx242-246).

Sources: server/endpoints/system.js943-1016 server/endpoints/admin.js496-559 server/models/apiKeys.js server/models/browserExtensionApiKey.js server/utils/middleware/validApiKey.js

System Settings Administration

System Settings Architecture

Sources: server/models/systemSettings.js server/utils/helpers/updateENV.js server/endpoints/system.js76-91 server/endpoints/system.js472-489

SystemSettings Model

The SystemSettings model at server/models/systemSettings.js manages application-level settings stored in the system_settings table. Each setting is a key-value pair:

Key methods:

SystemSettings.currentSettings() Aggregates configuration from multiple sources:

1. Environment variables via process.env
2. Database settings from system_settings table
3. Default values defined in the model

Returns a comprehensive settings object used by /setup-complete endpoint at server/endpoints/system.js83-91

SystemSettings.updateSettings(updates) High-level update method that:

• Accepts object with setting labels as keys
• Validates values based on setting type
• Writes to system_settings table
• Used by /admin/system-preferences at server/endpoints/admin.js481-494

SystemSettings._updateSettings(updates) Internal method for direct database writes without validation hooks. Used when bypassing the standard update flow.

SystemSettings.isMultiUserMode() Checks if multi-user mode is enabled:

Used throughout the codebase to conditionally enable multi-user features.

updateENV Utility

The updateENV() utility at server/utils/helpers/updateENV.js manages infrastructure-level configuration:

Key Features:

1. KEY_MAPPING - Maps friendly field names to environment variable names:

2. Validation - Validates values before applying (e.g., URL format, required fields)

3. Lifecycle Hooks - Executes pre/post-update logic:

   • beforeHooks - Run before setting env vars (e.g., validate credentials)
   • afterHooks - Run after setting env vars (e.g., reset vector DB cache)

4. Environment Persistence - In production mode, writes updates to .env file via dumpENV() at server/endpoints/system.js76-81

Example usage at server/endpoints/system.js472-489:

System Preferences Endpoint

The /admin/system-preferences endpoint at server/endpoints/admin.js420-479 provides read access to specific application settings:

GET Request: Supports query parameter ?labels=label1,label2,label3 to fetch specific settings. Returns:

Special handling for computed settings:

• max_embed_chunk_size - Derived from embedding engine capabilities
• agent_sql_connections - Retrieved via SystemSettings.brief.agent_sql_connections()
• imported_agent_skills - Listed via ImportedPlugin.listImportedPlugins()
• feature_flags - Aggregated via SystemSettings.getFeatureFlags()

POST Request: Updates settings via SystemSettings.updateSettings() at server/endpoints/admin.js487

Multi-User Mode Toggle

Enabling multi-user mode via /system/enable-multi-user at server/endpoints/system.js525-579 performs:

1. Check if already enabled at server/endpoints/system.js530-536
2. Create first admin user via User.create() at server/endpoints/system.js539-543
3. Set multi_user_mode: true via SystemSettings._updateSettings() at server/endpoints/system.js553-555
4. Migrate browser extension API keys at server/endpoints/system.js556
5. Generate JWT secret via updateENV() at server/endpoints/system.js558-563
6. Log telemetry and event at server/endpoints/system.js564-567

If any step fails, rollback occurs at server/endpoints/system.js570-576:

Sources: server/models/systemSettings.js server/utils/helpers/updateENV.js server/endpoints/system.js472-489 server/endpoints/system.js525-579 server/endpoints/admin.js420-494

Password Recovery System

The password recovery system allows users to regain access using recovery codes generated at first login.

Recovery Flow:

1. Recovery Code Generation at server/endpoints/system.js211-221

   • Occurs on first successful login when !existingUser.seen_recovery_codes
   • Generates codes via generateRecoveryCodes(userId) from server/utils/PasswordRecovery.js
   • Returns plaintext codes to user (shown only once)
   • Stores hashed codes in database

2. Account Recovery via /system/recover-account at server/endpoints/system.js313-336

   • Accepts username and recovery codes
   • Validates codes via recoverAccount() from server/utils/PasswordRecovery.js
   • Returns temporary reset token if valid

3. Password Reset via /system/reset-password at server/endpoints/system.js338-360

   • Accepts reset token, new password, and confirmation
   • Validates and updates password via resetPassword() from server/utils/PasswordRecovery.js
   • Invalidates reset token after use

Frontend recovery flows handled by:

• System.recoverAccount() at frontend/src/models/system.js86-103
• System.resetPassword() at frontend/src/models/system.js104-121

Sources: server/endpoints/system.js313-360 server/utils/PasswordRecovery.js frontend/src/models/system.js86-121

Frontend Administration UI

The admin interface is organized in the Settings Sidebar at frontend/src/components/SettingsSidebar/index.jsx214-413 with role-based menu visibility:

Admin-Only Sections:

• AI Providers (LLM, Vector DB, Embedder, Transcription)
• Default System Prompt
• Agent Skills
• Community Hub
• Event Logs
• API Keys
• System Prompt Variables
• Experimental Features

Manager + Admin Sections:

• Users Management
• Workspaces Management
• Invites
• Workspace Chats (if canViewChatHistory)
• Security Settings
• Customization (Interface, Branding, Chat)
• Browser Extension

Route guards enforce permissions:

• AdminRoute component at frontend/src/components/PrivateRoute - Requires admin role
• ManagerRoute component - Requires admin or manager role

Settings pages load via lazy imports at frontend/src/App.jsx26-98 and mount in protected routes at frontend/src/App.jsx138-299

Sources: frontend/src/components/SettingsSidebar/index.jsx214-413 frontend/src/App.jsx1-312 frontend/src/components/PrivateRoute