* docs: spec for admin/settings resolved runtime values (#7803) Side-channel resolved+redacted settings alongside raw file blob. Form view dropdowns and env pill chips reflect actual runtime values instead of falling back to template defaults. Save round-trip is unchanged so ${VAR:default} literals stay intact on disk. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: implementation plan for admin/settings resolved runtime (#7803) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(admin): add redactor for resolved settings payload (#7803) Pure helper that walks the live settings module and replaces known sensitive paths (users.*.password, dbSettings.password, sso.clients[*].client_secret, sessionKey, …) with [REDACTED] sentinel. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(admin): emit redacted runtime settings on /settings socket load (#7803) Existing 'results' raw-file blob is unchanged so the textarea editor and saveSettings round-trip continue to preserve \${VAR:default} literals on disk. New 'resolved' field carries the in-memory settings module run through the redactor — admin SPA can use it to show actual runtime values next to env-var placeholders. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(admin): show resolved runtime value on EnvPill (#7803) Admin SPA now stores the resolved field from the /settings socket payload and exposes useResolvedAt(path) to walk it. EnvPill renders a "→ active value" chip when the path is resolved, or "→ ••••••" with a redacted tooltip when the server returned the [REDACTED] sentinel. Old-server fallback (undefined resolved) keeps current behaviour. The admin test script glob now picks up .test.tsx alongside .test.ts so the new EnvPill tests run under tsx --test. Closes #7803. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| public | ||
| scripts | ||
| src | ||
| .eslintrc.cjs | ||
| .gitignore | ||
| index.html | ||
| package.json | ||
| README.md | ||
| tsconfig.json | ||
| tsconfig.node.json | ||
| vite.config.ts | ||
Admin UI
Vite + React 19 single-page app served at /admin. Talks to the backend over
socket.io for the existing settings / plugins / pads pages, and (when
endpoints are added to the OpenAPI spec) over a typed REST client.
Scripts
| Script | What it does |
|---|---|
pnpm dev |
gen:api + Vite dev server (expects backend on :9001). |
pnpm gen:api |
Regenerates src/api/{schema.d.ts,version.ts} from the OpenAPI spec. |
pnpm build |
gen:api + tsc + vite build. |
pnpm build-copy |
Same, but writes into ../src/templates/admin. |
pnpm test |
gen:api + smoke tests for the API client wiring. |
pnpm lint |
ESLint. |
Typed API client
The admin uses openapi-typescript to generate types from
src/node/hooks/express/openapi.ts, openapi-fetch for typed requests, and
openapi-react-query for TanStack Query bindings.
Generated files
admin/src/api/schema.d.ts and admin/src/api/version.ts are generated by
gen:api and gitignored — never commit them. They are produced by:
pnpm --filter admin gen:api
admin/scripts/gen-api.mjs loads src/node/hooks/express/openapi.ts, calls
generateDefinitionForVersion for the latest API version, pipes the JSON
through openapi-typescript to produce schema.d.ts, and emits a runtime
constant LATEST_API_VERSION (read from info.version in the spec) to
version.ts so client.ts can build the right /api/<version>/ baseUrl.
gen:api runs as the first step of dev, build, build-copy, and
test, so a fresh checkout produces the generated files automatically when
any of those scripts is invoked. After modifying any of the following, the
next pnpm <dev|build|test> will refresh the generated files; you can also
run gen:api directly:
src/node/hooks/express/openapi.tssrc/node/handler/APIHandler.ts(changes tolatestApiVersion)- the resource definitions referenced by
openapi.ts
Using the client
import { $api } from './api/client';
const SettingsPanel = () => {
const { data } = $api.useQuery('get', '/admin/settings'); // example
return <pre>{JSON.stringify(data, null, 2)}</pre>;
};
The admin endpoints are not yet present in the OpenAPI spec — this client is in place to support upcoming work (see issue #7638 follow-up). For now, it is exercised only by the smoke test.
Socket.io: padLoad query shape
The admin /settings namespace's padLoad event accepts a PadSearchQuery
defined in src/node/types/PadSearchQuery.ts:
| field | type | required | notes |
|---|---|---|---|
pattern |
string |
yes | Substring match on pad name. |
offset |
number |
yes | Pagination start, in items. Clamped server-side. |
limit |
number |
yes | Page size. Capped at 12. |
ascending |
boolean |
yes | Sort direction. |
sortBy |
"padName" | "lastEdited" | "userCount" | "revisionNumber" |
yes | Column to sort by. |
filter |
"all" | "active" | "recent" | "empty" | "stale" (opt.) |
no | Filter chip; defaults to "all". Applied before pagination so total and the page slice both reflect the filtered universe. Older clients that omit the field get the unchanged "all" behaviour. |
Filter semantics — applied after pattern matching, before sort + slice:
active:userCount > 0recent: edited within the last 7 daysempty:revisionNumber === 0stale: not edited in the last 365 daysall/ missing: no further filtering