Files
TREK/wiki/Admin-Panel-Overview.md
Maurice 7da0080557 docs(wiki): bring the wiki in line with 4.0.0 (#2034)
* docs(wiki): correct the install and operations pages for 4.0.0

Quick Start passed docker an empty ENCRYPTION_KEY: an assignment prefix is not
expanded on the same command line, so the server silently generated its own key
instead of taking the one the page told you to set. The tag examples pinned to
the 3.x line, the documented tmpfs size did not match the shipped compose file,
and several .env values were described as reaching the container when compose
never interpolates them.

* docs(wiki): match the MCP reference to the registered surface

The scope table was missing the whole Collections group and the totals said 27
scopes across 13 groups where the code registers 29 across 14. The Cloudflare
link on the setup page pointed at an anchor on its own page instead of the
heading on Troubleshooting.

* docs(wiki): correct the plugin and admin pages

Three links to Plugin-Development carried a .md suffix, which does not resolve on
the wiki. The admin pages described tabs, permissions and storage behaviour that
had moved on.

* docs(wiki): bring the feature pages back in line with the app

Costs still documented the old panel, where categories could be added, renamed,
reordered and deleted; they are fixed now and the panel is a day-grouped ledger
with settlements. Trip sharing, journeys, maps, packing, reservations and the
account pages had all drifted in the same way.

* docs(wiki): cover the pages the first pass did not reach

The MCP catalog listed 168 of the 201 registered tools; the settlement tools and
rate_place were missing here and the Collections family from the addon page.
Several resource rows claimed a trips:* scope where the handler asks for
trips:read.

* docs(wiki): tighten the corrections a review picked apart

The audit-log resource is the row id, not the credential id; an admin password
reset does not bump password_version the way the page implied; and a few of the
new paragraphs described behaviour more confidently than the code supports.

* docs(wiki): fix what a last read-through caught

Costs shows every figure in your display currency, not the trip's, and an
expense with no payer still counts against the members it is split between.
Studio's cutoff is a 1024px viewport rather than phones alone, and the
Integrations tab is gated on the providers an admin has configured.

* docs(wiki): the last few the review caught

A passkey satisfies the MFA policy everywhere except the WebSocket handshake,
which still asks for TOTP, so a passkey-only account under that policy gets no
live updates. Mobile optimizes a day from two places, not three. The ctx.db row
carried an unescaped pipe that split the table, and the Backups table linked
with a wiki link whose pipe did the same.
2026-08-25 12:36:52 +02:00

4.6 KiB

Admin Panel Overview

The Admin Panel is the central control surface for TREK instance operators. It is only accessible to users with the admin role.

Accessing the Admin Panel

Open the user menu in the top navigation bar (your avatar), then select Admin. If the entry is not there, your account does not have admin privileges.

Admin Panel

Tabs

The Admin Panel is divided into tabs. Most tabs are always visible; a few appear only under specific conditions.

Tab Purpose Conditional?
Users Manage users, invite links, and permissions No
Personalization Packing templates and place categories No
User Defaults Default settings applied to new users No
Addons Enable or disable optional features instance-wide No
Plugins Install, update, and manage plugins; rescan the plugins folder; view each plugin's error log. See Admin-Plugins No
Storage Storage backends, category assignment, replication, health Hidden on managed instances
Settings Authentication methods, MFA, allowed file types, API keys, OIDC/SSO configuration, and JWT secret rotation No
Notifications SMTP, webhook, ntfy, and push notification channel configuration; trip reminder toggle; admin notification preferences No
Backup Manual and scheduled full-instance backups: database, uploads, plugin data and plugin code. See Backups Hidden on managed instances
Audit Chronological activity log No
MCP Access OAuth sessions and static API tokens Only when the MCP addon is enabled
GitHub Release timeline and support links Hidden on managed instances
Dev: Notifications Test notification dispatch Only in development mode (NODE_ENV=development)

Admin panel on the User Defaults tab, setting instance-wide defaults for colour mode, temperature unit, distance unit, time format, currency and blurred booking codes

Linking to a tab directly

Every panel is reachable by URL, so a bookmark, an onboarding mail or a support reply can point at the one tab it is about instead of at the top of a page with thirteen of them:

/admin?tab=audit

Unlike the trip planner's tab parameter, this one stays in the address bar and is rewritten as you switch tabs, so the URL always says which panel you are looking at. It replaces the current history entry instead of adding one, so the back button still leaves the admin page rather than walking back through the tabs you visited.

Tab Id
Users users (the default — carries no ?tab=)
Personalization config
User Defaults defaults
Addons addons
Plugins plugins
Storage storage
Settings settings
Notifications notifications
Backup backup
Audit audit
MCP Access mcp-tokens
GitHub github
Dev: Notifications dev-notifications

An id with no panel behind it opens Users, and on a managed instance the three tabs hidden there — storage, github and backup — fall back to Users as well. The other two conditional tabs behave differently: mcp-tokens and dev-notifications open their panel even when the MCP addon is off or the instance is not in development mode, with nothing highlighted in the sidebar, because the entry is missing from it.

Plugin activity and audit

Plugins that are granted data-access capabilities have every host-mediated action they take recorded in a tamper-evident, hash-chained log. This log is separate from the instance Audit tab described above.

  • Admins can review the per-plugin capability audit — every core-data read, broadcast, notification, and AI call a plugin made, with the acting user, the resource touched, and the outcome. It is served by GET /api/admin/plugins/<id>/audit; the admin plugin view itself currently surfaces only each plugin's error log (View error log).
  • Every user (not just admins) can see the plugin actions taken in their own name under Settings → Plugins. This is what keeps a plugin's broad read grants accountable to the person whose data was read.

See Audit-Log for details on the hash chain and how the two logs differ.