Pull Request Checklist

Do not open a pull request as the first step.

For real, reproducible bugs, start with a well-described Issue that explains the problem, why it matters, and what outcome you are looking for.

For feature requests, enhancements, behavior changes, UI/UX changes, architecture changes, suspected fixes, or unconfirmed approaches, start with an active Discussion. Merely opening a discussion is not enough; it needs to be actively discussed.

If you want to propose an implementation, include it only as a reference in the Issue or Discussion, such as a local diff, patch, or branch.

Opening an Issue or Discussion does not mean a PR is the right next step. Maintainers will confirm when a PR would be useful.

We ask for this because PRs, especially from first-time contributors, often need broader maintainer context on product direction, scope, architecture, UX, edge cases, compatibility, documentation, and long-term maintenance before implementation.

Unsolicited PRs may be closed without review. Contributors with a history of successful merged PRs may be given more latitude.

Note: This PR is opened against the existing, maintainer-labeled bug issue #29190. It is intended as a concrete reference implementation for that issue — happy to hold it until maintainers confirm a PR is fully welcome.

Before submitting, make sure you've checked and filled out the following:

• Linked Issue/Discussion: This PR references an existing, well-described Issue for a real bug or an active, substantive Discussion for a feature request or enhancement — Closes #29190.
• First-time contributor policy: This is not my first contribution to Open WebUI, this PR contains only i18n/localization updates, or a maintainer explicitly asked me to open this PR after reviewing the linked Issue or Discussion. (Prior merged contribution: i18n: complete Polish (pl-PL) translation #29184.)
• Target branch: The pull request targets the dev branch. PRs targeting main will be immediately closed.
• Description: A concise description of the changes is provided below.
• Changelog: A changelog entry following Keep a Changelog format is included at the bottom.
• Documentation: N/A — no documentation changes are required; the fix makes existing UI behavior consistent with the tag already shown in the chat model selector.
• Dependencies: N/A — no new or updated dependencies.
• Testing: Manual end-to-end API-level tests were performed against a locally running server (scenarios and results described below), plus frontend type-check parity. See "Testing" for details.
• User-facing changes: The UI changes only in content of an existing dropdown (connection tags now appear in the Admin → Models tag filter). No layout changes; screenshots of the "before" state are available in issue feat: include connection tags in the Admin > Models tag filter #29190, "after" state described in Testing.
• No Unchecked AI Code: This PR is AI-assisted; it has been reviewed and manually tested as described below (the submitter has reviewed the full diff and test results).
• Self-Review: A self-review of the code has been performed, ensuring adherence to project coding standards.
• Architecture: Smart defaults are preferred over new settings. Local state is used for ephemeral UI logic. No new settings were introduced; the change reuses existing config reads (Config.get_many) and existing runtime-merged tags instead of adding new state.
• Git Hygiene: The PR is atomic (one logical fix + a small formatting commit required by CI), rebased on dev, and contains no unrelated feature work.
• Title Prefix: fix

Problem

#29190 — tags added to a provider connection (Admin → Settings → Connections → Edit Connection → Advanced → Tags) do not show up in the Admin → Settings → Models tag filter dropdown, even though the very same tags do appear on models in the New Chat model selector and correctly filter models there.

Root cause

Connection tags and model tags live in two different storage locations, and the Admin → Models page only reads one of them:

1. Where connection tags are stored. A tag added in Edit Connection → Advanced is saved into the per-connection entry of the persistent config — openai.api_configs / ollama.api_configs (frontend: src/lib/components/AddConnectionModal.svelte, tags = normalizeTags(connection.config?.tags)). It is not written to the model table.

2. Why the chat model selector shows them. When the runtime model list is built, both provider routers copy the connection tags onto every model served by that connection:

   • backend/open_webui/routers/openai.py (get_all_models_responses): tags = api_config.get('tags', []) → model['tags'] = tags
   • backend/open_webui/routers/ollama.py (get_all_models): allowed_tags = api_config.get('tags', []) → m['tags'] = allowed_tags

   and GET /api/models (backend/open_webui/main.py) additionally merges them with DB meta tags: tags = normalize_model_tags(meta.get('tags')) + normalize_model_tags(model.get('tags')). That is why the chat selector works.

3. Why the Admin → Models tag filter does not. The filter dropdown is fed by GET /api/v1/models/base/tags (backend/open_webui/routers/models.py), which calls Models.get_all_tags(...) (backend/open_webui/models/models.py). That method extracts tags exclusively from the meta JSON column of the model table. Connection tags are stored in the config store, not in that table — so they can never appear in the dropdown.

4. Filtering would also return nothing. Even if the dropdown listed a connection tag, selecting it calls GET /api/v1/models/base?tag=... → Models.get_base_models(tag=...), which filters DB rows by Model.meta tags. A connection tag matches no DB row, so the result would be an empty model list. Both the dropdown and the filtering path had to be fixed; fixing only the dropdown would have turned the bug into "tag visible, clicking it shows nothing".

As a side effect of the same root cause, two case variants of the same tag stored in the DB (e.g. Uncensored vs uncensored, visible in the issue's screenshot as "Uncensored" appearing twice) were both listed in the dropdown, because the deduplication set compared names case-sensitively.

Solution

Two minimal, targeted changes (single commit, rebased on dev):

1. Backend — backend/open_webui/routers/models.py

• New helper get_connection_tags(): reads openai.enable / openai.api_configs / ollama.enable / ollama.api_configs via the existing Config.get_many(...) pattern (same idiom already used by get_all_base_models in backend/open_webui/utils/models.py) and collects the tag names of enabled connections only. Per-connection enable defaults to True, mirroring the routers.
• New helper _get_connection_tag_names(): normalizes each connection's tags list with the already-existing normalize_model_tags() (handles both [{name}] dicts and legacy plain strings) and skips non-dict entries defensively.
• GET /api/v1/models/base/tags now returns DB meta tags ∪ connection tags, deduplicated case-insensitively (keeping the first name in sort order as the canonical casing), sorted case-insensitively. This fixes both the missing tags and the duplicate Uncensored entry from the issue's screenshot.

2. Frontend — src/lib/components/admin/Settings/Models.svelte

• The tag filter predicate gained a fallback: a model matches the selected tag if it is present in the tag-filtered base-model query (existing behavior, DB tags) or if the tag is present in the runtime tags that /api/models already merged into the model list (connection tags). This is done entirely with data the page already fetches — no extra requests, no provider calls from the tag-filter path.
• ModelListItem type extended with the optional tags field (string | { name } items are both handled, since provider/base endpoints and the aggregated endpoint use slightly different shapes).

Why not another approach

• Doing it fully on the backend (making Models.get_base_models(tag) connection-aware) would require resolving which models each connection serves — that means live provider fetches on every tag selection, or denormalizing connection→model mappings into the DB. The runtime list already carries the merged tags, so the frontend fallback is the smallest correct change.
• No new settings, no schema changes, no new endpoints.

Testing

End-to-end verified against a locally running server (uvicorn open_webui.main:app, fresh SQLite data dir, first user = admin):

UI-level verification steps for reviewers: add a tag to an OpenAI-compatible connection (Admin → Connections → Advanced), open Admin → Models → Tags dropdown — the tag now appears; selecting it shows all models served by that connection. The tag previously appeared in the chat model selector only.

Changelog Entry

Description

• Tags added to provider connections (Admin → Connections → Advanced) were merged into the runtime model list (/api/models) and therefore visible in the chat model selector, but were invisible to the Admin → Models tag filter because /api/v1/models/base/tags and /api/v1/models/base derive tags solely from the model table, while connection tags live in the connection config (openai.api_configs / ollama.api_configs). The tag filter now includes connection tags and filtering by them returns the models served by that connection. Case-variant duplicates of the same tag no longer appear multiple times in the dropdown. Fixes feat: include connection tags in the Admin > Models tag filter #29190.

Added

• get_connection_tags() / _get_connection_tag_names() helpers in the models router collecting tag names from enabled provider connections.

Changed

• GET /api/v1/models/base/tags now returns the union of model-DB tags and connection tags, deduplicated case-insensitively.
• Admin → Models tag filtering falls back to runtime-merged tags so connection-tagged models match.

Deprecated

• None.

Removed

• None.

Fixed

• Connection tags missing from the Admin → Models tag filter (and filtering by them returning an empty list) — feat: include connection tags in the Admin > Models tag filter #29190.
• Duplicate dropdown entries for tags differing only in letter case.
• Missing trailing newline at end of src/lib/i18n/locales/pl-PL/translation.json (pre-existing formatting drift since i18n: complete Polish (pl-PL) translation #29184, caught by the Format & Build prettier pass).

Security

• No security impact; the endpoint remains admin-only and reads only server-side config.

Breaking Changes

• None.

Additional Information

• Note on CI: the Format & Build check currently fails on a pre-existing formatting issue in src/app.css that is already present on dev itself (npx prettier --stdin-filepath src/app.css --check fails against the unmodified dev tree). It is unrelated to this PR and left untouched here; every open PR will hit it until dev receives a formatting pass.
• Fixes feat: include connection tags in the Admin > Models tag filter #29190 (maintainer-labeled bug, reproduced and root-caused as described above).
• The reported "Uncensored shows up twice" oddity is also addressed (case-insensitive deduplication).
• No dependencies added; no database migrations; no new settings.

Screenshots or Videos

• "Before" screenshots are available in issue feat: include connection tags in the Admin > Models tag filter #29190. The "after" state is a purely additive dropdown content change (connection tags listed); API-level before/after outputs are captured in the Testing table above. Happy to attach UI screenshots on request.

Contributor License Agreement

• By submitting this pull request, I confirm that I have read and fully agree to the Contributor License Agreement (CLA), and I am providing my contributions under its terms.