33 lines
1.7 KiB
Markdown
33 lines
1.7 KiB
Markdown
---
|
|
id: settings/the-same-for-system-settings-owned-by-the
|
|
title: "The same for system settings, owned by the Super Admin"
|
|
theme: settings
|
|
status: open
|
|
created: 2026-08-22
|
|
date_source: stated
|
|
order: 2
|
|
---
|
|
|
|
**The same for system settings, owned by the Super Admin.** Wanted 2026-08-22, in the same breath as the
|
|
per-user export — the server's own configuration should be a file too, so a new instance can be brought
|
|
up matching an existing one instead of being clicked into shape.
|
|
|
|
This is the half with the larger payoff, because it is the half that is currently repeated per machine.
|
|
`docs/servers.md` lists **seven platforms running**, each configured by hand, and nothing anywhere
|
|
records what a given server's settings actually are. A file makes that answerable, diffable between two
|
|
hosts, and reviewable in git.
|
|
|
|
`server_config` is already key/value jsonb, so the export is close to free. Two things make it a
|
|
different problem from the user one rather than the same problem twice:
|
|
|
|
- **Some system settings are legitimately per machine** — anything naming a host, a port, a path or a
|
|
device. An import that overwrites those turns a working server into a copy of another one. The export
|
|
needs to distinguish portable configuration from machine identity, and that split does not exist
|
|
anywhere today.
|
|
- **Ownership is the Super Admin, and only the Super Admin.** `execution` and `admin` permissions are
|
|
stripped for every other role even when granted, so the route carrying this is owner-only by the same
|
|
rule — worth stating so nobody makes it a role grant later.
|
|
|
|
Do this alongside `settings/a-user-s-settings-should-export-and-import-as` — one format, two scopes.
|
|
The credential rule from that item applies unchanged: carry the shape, never the secret.
|