[PR #1390] [MERGED] docs: explain what Private means per resource type and how Public combines with the access list #1354

New issue

Closed

opened 2026-10-18 14:19:05 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 14:19:05 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/open-webui/docs/pull/1390
Author: @silentoplayz
Created: 9/14/2026
Status: ✅ Merged
Merged: 9/18/2026
Merged by: @silentoplayz

Base: main ← Head: docs/access-control-resource-families-and-public-grants

📝 Commits (1)

3696d18 docs: explain what private means per resource type and how public combines with the access list

📊 Changes

3 files changed (+23 additions, -1 deletions)

View changed files

📝 docs/features/authentication-access/rbac/groups.md (+20 -0)
📝 docs/features/authentication-access/rbac/roles.md (+1 -1)
📝 docs/reference/env-configuration.mdx (+2 -0)

📄 Description

Summary

The RBAC pages describe access grants for models and knowledge bases. The MCP, Open Terminal, and Evaluations pages each say their resource has access control. No page says what Private with an empty access list means, and the answer differs by resource type. No page says how the Public setting combines with rows in the access list either. This PR adds both.

Changes:

Groups page, Resource Access section. Two new subsections. The first explains that a private workspace item is owner-only, while a private admin-configured resource (external tool server, MCP server, Open Terminal connection, arena model) is admin-only, since it has no owner. The second explains that Public is one more grant, that rows survive a visibility switch, which rows still matter on a Public resource, and what the public write toggle stores.
Roles page. The BYPASS_ADMIN_ACCESS_CONTROL exception now names both resource families instead of "model/knowledge/notes resources", and links to the new subsection.
Environment reference. The BYPASS_ADMIN_ACCESS_CONTROL entry gains a paragraph saying the flag also governs admin-configured resources, and what an empty access list means for them.

Two open issues in the main repository cover surfaces that do not yet apply the admin-only rule. The tool server picker case is https://github.com/open-webui/open-webui/issues/30012 and the arena model case is https://github.com/open-webui/open-webui/issues/30013.

Checklist

I have reviewed the relevant documentation and matched the existing style.
This PR meets Open WebUI's contribution standards: it is accurate, relevant to users, narrowly scoped, maintainable, and not promotional content, advertising, lead generation, SEO placement, or a request to list a product, service, provider, integration, gateway, tool, or company primarily for visibility.
I understand that PRs that do not meet these standards may be closed without review and will not be merged. Repeated, low-quality, off-topic, promotional, or intentionally misleading submissions may result in the contributor being blocked from future participation in Open WebUI repositories.

Notes for reviewers

Every behavior claim was checked against the access control modal and the backend checks on dev.

Public is stored as a wildcard user read grant. The visibility dropdown adds or removes only wildcard grants, so user and group rows persist across a switch.
Choosing Write on a row stores read and write together. The public write toggle stores a wildcard user write grant.
Both backend checks match the permission exactly, so a Read row on a Public resource has no effect until the resource goes back to Private.
Workspace items list through a filter with an owner clause, so a private item with no grants is visible to its owner.
The shared connection check treats an empty grant list as admin-only. That is the contract the tool server picker and arena models do not yet honor.

I verified both lockouts on my own instance with the admin bypass off. The tool server picker case used an OpenAPI connection and an MCP connection, and the arena model case had both bypass flags off.

No screenshots. The change is text only.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/docs/pull/1390 **Author:** [@silentoplayz](https://github.com/silentoplayz) **Created:** 9/14/2026 **Status:** ✅ Merged **Merged:** 9/18/2026 **Merged by:** [@silentoplayz](https://github.com/silentoplayz) **Base:** `main` ← **Head:** `docs/access-control-resource-families-and-public-grants` --- ### 📝 Commits (1) - [`3696d18`](https://github.com/open-webui/docs/commit/3696d18f5b77a75cb93a12d1a9f73d6a5e2a0a00) docs: explain what private means per resource type and how public combines with the access list ### 📊 Changes **3 files changed** (+23 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `docs/features/authentication-access/rbac/groups.md` (+20 -0) 📝 `docs/features/authentication-access/rbac/roles.md` (+1 -1) 📝 `docs/reference/env-configuration.mdx` (+2 -0) </details> ### 📄 Description ## Summary The RBAC pages describe access grants for models and knowledge bases. The MCP, Open Terminal, and Evaluations pages each say their resource has access control. No page says what **Private** with an empty access list means, and the answer differs by resource type. No page says how the Public setting combines with rows in the access list either. This PR adds both. Changes: - **Groups page, Resource Access section.** Two new subsections. The first explains that a private workspace item is owner-only, while a private admin-configured resource (external tool server, MCP server, Open Terminal connection, arena model) is admin-only, since it has no owner. The second explains that Public is one more grant, that rows survive a visibility switch, which rows still matter on a Public resource, and what the public write toggle stores. - **Roles page.** The `BYPASS_ADMIN_ACCESS_CONTROL` exception now names both resource families instead of "model/knowledge/notes resources", and links to the new subsection. - **Environment reference.** The `BYPASS_ADMIN_ACCESS_CONTROL` entry gains a paragraph saying the flag also governs admin-configured resources, and what an empty access list means for them. ## Related issue or discussion Two open issues in the main repository cover surfaces that do not yet apply the admin-only rule. The tool server picker case is https://github.com/open-webui/open-webui/issues/30012 and the arena model case is https://github.com/open-webui/open-webui/issues/30013. ## Checklist - [x] I have reviewed the relevant documentation and matched the existing style. - [x] This PR meets Open WebUI's contribution standards: it is accurate, relevant to users, narrowly scoped, maintainable, and not promotional content, advertising, lead generation, SEO placement, or a request to list a product, service, provider, integration, gateway, tool, or company primarily for visibility. - [x] I understand that PRs that do not meet these standards may be closed without review and will not be merged. Repeated, low-quality, off-topic, promotional, or intentionally misleading submissions may result in the contributor being blocked from future participation in Open WebUI repositories. ## Notes for reviewers Every behavior claim was checked against the access control modal and the backend checks on `dev`. - Public is stored as a wildcard user read grant. The visibility dropdown adds or removes only wildcard grants, so user and group rows persist across a switch. - Choosing Write on a row stores read and write together. The public write toggle stores a wildcard user write grant. - Both backend checks match the permission exactly, so a Read row on a Public resource has no effect until the resource goes back to Private. - Workspace items list through a filter with an owner clause, so a private item with no grants is visible to its owner. - The shared connection check treats an empty grant list as admin-only. That is the contract the tool server picker and arena models do not yet honor. I verified both lockouts on my own instance with the admin bypass off. The tool server picker case used an OpenAPI connection and an MCP connection, and the arena model case had both bypass flags off. No screenshots. The change is text only. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-18 14:19:05 +00:00