Which page writes which subtree#

Every editor in the web interface changes one part of the router's configuration tree, and with Advanced mode on, each page names that part beside its title. The tables below map it both ways: screen to tree, and node to the screen that edits it. These are the router's own configuration paths, not a Wheelhouse schema.

By page#

/wan redirects to /ha.

By subtree#

Three pages hide themselves#

A page is never hidden while the configuration it edits is live on the router. A feature module's catalogue entry declares the config_path that decides it — see Catalogue schema.

Four pages are admin-only and absent otherwise: Users, API tokens, Agent settings and Licence.

Every page adds to the pending changes; only the Commit Bar applies#

Every editor adds its changes to the pending changes, and only the Commit Bar applies them. Whatever page a change came from, it appears in the Commit Bar's list before it is applied, as a sentence or, in Advanced mode, as the same set and delete lines, and the audit log records who applied it.

The Configuration tree page changes nothing. It renders any setting as the commands that recreate it, and adds nothing to the pending changes. A setting that no page edits is changed through the API (POST /api/stage), a desired-state file that the Reconcile page compares with the router, or the router's console.

Re-deriving this table#

grep -rn '<PageHeader' ui/src/pages/*.tsx -A 4 | grep -E 'title=|path='
grep -n 'to:' ui/src/components/nav.ts

See also#

• The commands Wheelhouse runs — the reads behind each page.
• Endpoint index — the endpoint each page calls.
• Catalogue schema — feature modules and config_path.
• Role matrix — who sees the admin pages.
• The desired-state file — what the Reconcile page reads.
• The configuration tree
• The Commit Bar