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?

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_
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @kfsone on GitHub (May 29, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/14507
Check Existing Issues
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:
-- 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,
Approach 2: "Unassigned" Group
Approach 3: Endpoint <-> group associations
Approach 4: #@trust tag
Alternatives Considered
No response
Additional Context
No response