Skip to content

feat: implement dynamic settings UI with auto-discovery and basic/advanced toggle #454

@Aureliolo

Description

@Aureliolo

Summary

The web dashboard Settings page should dynamically render all available settings by reading the settings metadata registry from the API. No manual UI work should be needed when new settings are added to the backend — the UI discovers and renders them automatically.

Problem

Currently every settings section in the UI must be manually coded: provider cards, budget fields, etc. This means:

  • Adding a new config field requires a frontend change
  • Settings pages are always incomplete or out of date
  • No consistency in how settings are presented

Design

Backend: Settings Schema API

The settings persistence layer (#450) includes a metadata registry where every setting is registered with:

```
namespace, key, type, default, description, group, level (BASIC/ADVANCED), sensitive, restart_required
```

The API exposes this:

  • `GET /api/v1/settings/_schema` — full registry grouped by namespace
  • `GET /api/v1/settings/_schema/{namespace}` — schema for one namespace
  • `GET /api/v1/settings/{namespace}` — current resolved values

Frontend: Dynamic Form Renderer

A generic `SettingsSection.vue` component that:

  1. Fetches the schema for a namespace
  2. Groups settings by `group` field
  3. Renders appropriate input for each `type`:
    • `str` → text input
    • `int` / `float` → number input with validation
    • `bool` → toggle switch
    • `enum` → dropdown select
    • `json` → code editor (Monaco or similar)
    • `sensitive` → password input with "saved" indicator, never echoes back
  4. Shows `description` as help text
  5. Shows `restart_required` badge if applicable
  6. Saves via `PUT /api/v1/settings/{namespace}/{key}`
  7. Reset-to-default button per setting (`DELETE`)

Basic / Advanced Toggle

  • Settings page has a global toggle: Basic (default) / Advanced
  • In Basic mode: only settings with `level: BASIC` are shown
  • In Advanced mode: all settings shown, with `ADVANCED` ones visually distinguished (e.g. subtle border or "Advanced" chip)
  • Toggle state persisted in localStorage (not a backend setting)
  • Each namespace/group only appears if it has at least one visible setting in the current mode

Settings Page Layout

```
Settings
├── [Basic / Advanced toggle]
├── Providers (custom component — cards, not generic form. See #451)
├── Company (dynamic: name, description, defaults)
├── Budget (dynamic: global limits, daily caps, auto-downgrade thresholds)
├── Memory (dynamic: backend selection, retention, consolidation settings)
├── Security (dynamic: trust strategy, autonomy level, scan policies)
├── Coordination (dynamic: topology, wave config)
├── Observability (dynamic: log level, sinks, correlation)
├── Backup (dynamic: schedule, retention, path — see #449)
└── System (dynamic: maintenance mode, feature flags)
```

All sections except Providers use the generic dynamic renderer. Providers has a custom UI (cards, test button, credential input) but still reads schema for its fields.

Adding a New Setting (Developer Workflow)

  1. Add `SettingDefinition` to the registry in Python backend (namespace, key, type, default, description, group, level)
  2. That's it. The UI discovers it automatically on next page load.

No frontend code changes needed for new settings.

Dependencies

Acceptance Criteria

  • `GET /api/v1/settings/_schema` returns full typed metadata registry
  • Generic `SettingsSection.vue` renders forms from schema
  • Type-appropriate inputs (text, number, toggle, select, password, code editor)
  • Basic/Advanced toggle filters visible settings
  • Toggle state persisted in localStorage
  • Save via PUT, reset-to-default via DELETE
  • Description as help text, restart_required badge
  • Groups and namespaces auto-organized
  • Adding a new SettingDefinition in Python → auto-appears in UI (no frontend change)
  • Providers section uses custom component but shares schema for field definitions

Metadata

Metadata

Assignees

No one assigned

    Labels

    prio:highImportant, should be prioritizedscope:large3+ days of workspec:architectureDESIGN_SPEC Section 15 - Technical Architecturespec:human-interactionDESIGN_SPEC Section 13 - Human Interaction Layerspec:providersDESIGN_SPEC Section 9 - Model Provider Layerspec:securityDESIGN_SPEC Section 12 - Security & Approval Systemtype:featureNew feature implementation

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions