[GH-ISSUE #14507] feat: Between private and public. #17281

New Issue

GiteaMirror · 2026-04-19T22:59:50-05:00

GiteaMirror commented

2026-04-19 22:59:50 -05:00

Originally created by @kfsone on GitHub (May 29, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/14507

Check Existing Issues

I have searched the existing issues and discussions.

Problem Description

This is not privacy bypass or default public: I want group-based restriction but in a secure way. I'm filing this as a bug because the current approach does not follow best practices, and is unwieldy. For contrast, imagine if every time you created a new directory you had to assign it a group, and if you didn't, you would have to open settings/control panel to configure finder/explorer to allow you to see it?

This is especially tedious in small scenarios (a self-contained docker container that only hosts one image at a time, but you always have to use two UIs to make it usable) and large or dynamic installations.

Desired Solution you'd like

Approach 1: Discriminate between admin and user roles:

Admin accounts see ALL models in model drop-downs.
-- add a separator line at the bottom of the list, followed by unusable models,
-- grey-out/disable models the admin can't "use",
-- italicize private models with no group/user,
Admin account sees a widget to the right of each model that opens the model settings,

Approach 2: "Unassigned" Group

A group, default membership = admins, to which all models are assigned by default,

Approach 3: Endpoint <-> group associations

Allow (and emphasize) group<->tag association, so that tagging a connection ("#admins") would automatically add its models to that group or,
Provide a per-connection endpoint that sets a single default group, models are still private but visible to that group,

Approach 4: #@trust tag

Allow automatic publicity of models on a connection by assigning it the "#@trust" tag,

Alternatives Considered

No response

Additional Context

No response

Originally created by @kfsone on GitHub (May 29, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/14507 ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description This is not privacy bypass or default public: I *want* group-based restriction but in a secure way. I'm filing this as a bug because the current approach does not follow best practices, and is unwieldy. For contrast, imagine if every time you created a new directory you *had* to assign it a group, and if you didn't, you would have to open settings/control panel to configure finder/explorer to allow you to see it? ![Image](https://github.com/user-attachments/assets/d1682d5e-3c46-49f8-81b1-5f1d15585548) This is especially tedious in small scenarios (a self-contained docker container that only hosts one image at a time, but you always have to use *two* UIs to make it usable) and large or dynamic installations. ### Desired Solution you'd like Approach 1: Discriminate between admin and user roles: - Admin accounts see ALL models in model drop-downs. -- add a separator line at the bottom of the list, followed by unusable models, -- grey-out/disable models the admin can't "use", -- italicize private models with no group/user, - Admin account sees a widget to the right of each model that opens the model settings, Approach 2: "Unassigned" Group - A group, default membership = admins, to which all models are assigned by default, Approach 3: Endpoint <-> group associations - Allow (and emphasize) group<->tag association, so that tagging a connection ("#admins") would automatically add its models to that group or, - Provide a per-connection endpoint that sets a single default group, models are still private but visible to that group, Approach 4: #@trust tag - Allow automatic publicity of models on a connection by assigning it the "#@trust" tag, ### Alternatives Considered _No response_ ### Additional Context _No response_

GiteaMirror closed this issue

2026-04-19 22:59:50 -05:00

GiteaMirror referenced this issue

2026-04-20 05:22:28 -05:00

[PR #17281] [MERGED] chore: Changelog 0.6.27 - New Changelog Style #24379

GiteaMirror referenced this issue

2026-04-25 12:25:30 -05:00

[PR #17281] [MERGED] chore: Changelog 0.6.27 - New Changelog Style #40009

GiteaMirror referenced this issue

2026-04-29 22:38:09 -05:00

[PR #17281] [MERGED] chore: Changelog 0.6.27 - New Changelog Style #47427

GiteaMirror referenced this issue