[GH-ISSUE #24236] feat: environment variable to seed default user UI settings (landingPageMode, chatBubble, ...) for new and existing users #58903

New Issue

GiteaMirror · 2026-05-06T00:23:46-05:00

GiteaMirror commented

2026-05-06 00:23:46 -05:00

Originally created by @Flo5k5 on GitHub (Apr 29, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24236

Problem

There is currently no way for an administrator to set defaults for per-user UI settings like landingPageMode, chatBubble, chatDirection, richTextInput, widescreenMode, etc.

Concretely:

No environment variable to seed defaults at startup. The frontend reads $settings?.landingPageMode ?? '', $settings?.chatBubble ?? true, and so on — defaults are hardcoded inline in Svelte components, with no way to override globally.
No admin HTTP endpoint to push settings to other users. The only settings endpoints (GET/POST /api/v1/users/user/settings, GET/POST /api/v1/users/user/settings/update) are session-user scoped (Depends(get_verified_user)), so an admin token cannot patch another user's settings.ui.*.
No "default user settings" page in Admin Settings. There is Admin Settings > Default Permissions (powered by DEFAULT_USER_PERMISSIONS_*) but no equivalent for UI preferences.

The combined effect is that an organization deploying Open WebUI for, say, 100 alpha users cannot enforce a default UI preference (e.g. "everyone should land directly on the chat input instead of the welcome screen") without writing a SQL UPDATE against the user.settings JSON column.

Use case

We deploy Open WebUI on Azure Container Apps (Bicep) for our internal AI assistant ("QimIA"). We standardize the user experience by pinning a number of WEBUI_* / OAUTH_* / DEFAULT_* env vars in our IaC. After a round of feedback from alpha users, we want to default landingPageMode = 'chat' for everyone — i.e. land directly on a new conversation rather than the welcome/suggestions screen, similar to ChatGPT/Claude.

Today, we have to:

Run a one-shot SQL UPDATE on user.settings -> ui -> landingPageMode to backfill existing users.
Schedule a recurring SQL sweeper (we use an Azure Container Apps Job on a 6h cron) so that newly OAuth-created users converge to the same default within at most one cycle.
Document this in a runbook so the next engineer who restores a Postgres snapshot remembers to re-apply.

This works but it is brittle, not reproducible from the IaC, and very repo-specific.

Proposed solution

Introduce one of the following (in increasing order of scope):

Option A — minimal: `DEFAULT_USER_SETTINGS_JSON` env var

A single JSON-string env var whose contents are merged into a fresh user's settings.ui at first login (OAuth signup or local signup). Only applies to new users, no impact on existing ones.

DEFAULT_USER_SETTINGS_JSON: |
  {
    "ui": {
      "landingPageMode": "chat",
      "chatBubble": true,
      "chatDirection": "auto"
    }
  }

Implementation: a small block in signin_with_* / signup paths under backend/open_webui/utils/auth.py (or wherever the new User row is constructed) that pulls the env var, parses it, and assigns to user.settings.

Option B — extended: also apply to existing users on each startup

Same env var, but each container restart performs a non-destructive merge for users whose corresponding key is missing (COALESCE(... ->> 'X', '') = ''). Idempotent. This avoids the need for a recurring sweeper at all.

Caveat: respects user-overridden values once they have been explicitly set (the merge only writes when the key is absent).

Option C — full: admin HTTP endpoint + Admin Settings page

Expose POST /api/v1/users/{user_id}/settings/update (admin-only) and add an "Apply default UI settings to all users" button under Admin Settings > Interface. Most flexible, but more surface area to design.

We would be very happy with Option A or B alone — it covers 90% of multi-user deployments.

Alternatives considered

SQL sweeper as an ACA Job: works but ties the deployment to ops scripts that aren't in the upstream repo. Cf. our internal QIA-100 ticket.
Custom fork: defaults a different ?? value in the Svelte components. Maintenance burden of keeping the fork in sync.
Admin "save as default model" (issue #20165) — only covers the model selector, not the broader UI preferences.

Additional context

Open WebUI version: 0.6.x
Deployment: Azure Container Apps + Postgres pgvector + Entra ID OAuth
Roughly 50–100 internal alpha users
Backend code reference: backend/open_webui/models/users.py class UserSettings(BaseModel): ui: Optional[dict] = {} — already a free-form dict, so Option A/B don't require new schema.
Frontend code references: src/lib/components/chat/Settings/Interface.svelte (init let landingPageMode = '', let chatBubble = true, ...), src/lib/components/chat/Suggestions.svelte ($settings?.landingPageMode === 'chat').
i18n: in French, "Landing Page Mode" → "Mode de la page d'accueil", and the option 'chat' → "Conversation". Worth knowing for non-EN users describing the desired behavior.

Happy to contribute a PR for Option A or B if there is interest from maintainers.

Originally created by @Flo5k5 on GitHub (Apr 29, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24236 ## Problem There is currently **no way for an administrator to set defaults for per-user UI settings** like `landingPageMode`, `chatBubble`, `chatDirection`, `richTextInput`, `widescreenMode`, etc. Concretely: 1. **No environment variable** to seed defaults at startup. The frontend reads `$settings?.landingPageMode ?? ''`, `$settings?.chatBubble ?? true`, and so on — defaults are hardcoded inline in Svelte components, with no way to override globally. 2. **No admin HTTP endpoint** to push settings to other users. The only settings endpoints (`GET/POST /api/v1/users/user/settings`, `GET/POST /api/v1/users/user/settings/update`) are session-user scoped (`Depends(get_verified_user)`), so an admin token cannot patch another user's `settings.ui.*`. 3. **No "default user settings" page in Admin Settings**. There is `Admin Settings > Default Permissions` (powered by `DEFAULT_USER_PERMISSIONS_*`) but no equivalent for UI preferences. The combined effect is that an organization deploying Open WebUI for, say, 100 alpha users cannot enforce a default UI preference (e.g. "everyone should land directly on the chat input instead of the welcome screen") without writing a SQL UPDATE against the `user.settings` JSON column. ## Use case We deploy Open WebUI on Azure Container Apps (Bicep) for our internal AI assistant ("QimIA"). We standardize the user experience by pinning a number of `WEBUI_*` / `OAUTH_*` / `DEFAULT_*` env vars in our IaC. After a round of feedback from alpha users, we want to default `landingPageMode = 'chat'` for everyone — i.e. land directly on a new conversation rather than the welcome/suggestions screen, similar to ChatGPT/Claude. Today, we have to: 1. Run a one-shot SQL UPDATE on `user.settings -> ui -> landingPageMode` to backfill existing users. 2. Schedule a recurring SQL sweeper (we use an Azure Container Apps Job on a 6h cron) so that newly OAuth-created users converge to the same default within at most one cycle. 3. Document this in a runbook so the next engineer who restores a Postgres snapshot remembers to re-apply. This works but it is brittle, not reproducible from the IaC, and very repo-specific. ## Proposed solution Introduce one of the following (in increasing order of scope): ### Option A — minimal: `DEFAULT_USER_SETTINGS_JSON` env var A single JSON-string env var whose contents are merged into a fresh user's `settings.ui` at first login (OAuth signup or local signup). Only applies to **new** users, no impact on existing ones. ```yaml DEFAULT_USER_SETTINGS_JSON: | { "ui": { "landingPageMode": "chat", "chatBubble": true, "chatDirection": "auto" } } ``` Implementation: a small block in `signin_with_*` / `signup` paths under `backend/open_webui/utils/auth.py` (or wherever the new `User` row is constructed) that pulls the env var, parses it, and assigns to `user.settings`. ### Option B — extended: also apply to existing users on each startup Same env var, but each container restart performs a **non-destructive merge** for users whose corresponding key is missing (`COALESCE(... ->> 'X', '') = ''`). Idempotent. This avoids the need for a recurring sweeper at all. Caveat: respects user-overridden values once they have been explicitly set (the merge only writes when the key is absent). ### Option C — full: admin HTTP endpoint + Admin Settings page Expose `POST /api/v1/users/{user_id}/settings/update` (admin-only) and add an "Apply default UI settings to all users" button under `Admin Settings > Interface`. Most flexible, but more surface area to design. We would be very happy with Option A or B alone — it covers 90% of multi-user deployments. ## Alternatives considered - **SQL sweeper as an ACA Job**: works but ties the deployment to ops scripts that aren't in the upstream repo. Cf. our internal QIA-100 ticket. - **Custom fork**: defaults a different `??` value in the Svelte components. Maintenance burden of keeping the fork in sync. - **Admin "save as default model"** (issue #20165) — only covers the model selector, not the broader UI preferences. ## Additional context - Open WebUI version: 0.6.x - Deployment: Azure Container Apps + Postgres pgvector + Entra ID OAuth - Roughly 50–100 internal alpha users - Backend code reference: `backend/open_webui/models/users.py` `class UserSettings(BaseModel): ui: Optional[dict] = {}` — already a free-form dict, so Option A/B don't require new schema. - Frontend code references: `src/lib/components/chat/Settings/Interface.svelte` (init `let landingPageMode = ''`, `let chatBubble = true`, ...), `src/lib/components/chat/Suggestions.svelte` (`$settings?.landingPageMode === 'chat'`). - i18n: in French, "Landing Page Mode" → "Mode de la page d'accueil", and the option `'chat'` → "Conversation". Worth knowing for non-EN users describing the desired behavior. Happy to contribute a PR for Option A or B if there is interest from maintainers.

GiteaMirror closed this issue

2026-05-06 00:23:47 -05:00

GiteaMirror commented

2026-05-06 00:23:54 -05:00

@Classic298 commented on GitHub (Apr 29, 2026):

Duplicate and there is an existing open PR for it

@Classic298 commented on GitHub (Apr 29, 2026): Duplicate and there is an existing open PR for it

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#58903

[GH-ISSUE #24236] feat: environment variable to seed default user UI settings (landingPageMode, chatBubble, ...) for new and existing users #58903