[GH-ISSUE #21377] issue: [object Object] error when changing model access control in Admin Panel (v0.8.0) #58125

New Issue

Closed

opened 2026-05-05 22:23:50 -05:00 by GiteaMirror · 6 comments

GiteaMirror commented 2026-05-05 22:23:50 -05:00

Owner

Copy Link

Originally created by @ahgray on GitHub (Feb 13, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21377

Check Existing Issues

• I have searched for any existing and/or related issues.
• I have searched for any existing and/or related discussions.
• I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
• I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.8.0

Ollama Version (if applicable)

n/a

Operating System

Ubuntu 22.04 w/Docker

Browser (if applicable)

Firefox 147 also reproduced on Chrome

Confirmation

• I have read and followed all instructions in README.md.
• I am using the latest version of both Open WebUI and Ollama.
• I have included the browser console logs.
• I have included the Docker container logs.
• I have provided every relevant configuration, setting, and environment variable used in my setup.
• I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
• I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
• Start with the initial platform/version/OS and dependencies used,
• Specify exact install/launch/configure commands,
• List URLs visited, user input (incl. example values/emails/passwords if needed),
• Describe all options and toggles enabled or changed,
• Include any files or environmental changes,
• Identify the expected and actual result at each stage,
• Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

The model's access control should update successfully and display a success toast notification.

Actual Behavior

An [object Object] error toast appears. The access control change does not persist — refreshing the page shows the model retains its original access control setting.

Steps to Reproduce

Log in as an admin user.
Navigate to Admin Panel → Settings → Models.
Click the edit (pencil) icon on any model.
Change the Access Control dropdown from Private to Public (or any other change).
Observe the [object Object] error toast in the top-right corner.

Logs & Screenshots

Browser Console Output
The browser Network tab reveals the root cause:
XHRPOST http://10.0.7.114:3000/api/v1/models/model/access/update
[HTTP/1.1 404 Not Found 6ms]

Status: 404 Not Found
The URL contains the literal string model where the actual model ID should be (e.g., it should be /api/v1/models/gpt-4o/access/update or /api/v1/models/llama3:latest/access/update). The frontend component is passing a hardcoded or incorrectly-bound variable to the API call instead of the selected model's actual ID.
The 404 JSON response ({"detail": "Not Found"}) is then displayed as [object Object] in the toast, likely because the error handler calls something like toast.error(error) on the response object rather than extracting the string (e.g., toast.error(error.detail)).
Full console output:
SES Removing unpermitted intrinsics lockdown-install.js:1:203117
Removing intrinsics.%MapPrototype%.getOrInsert lockdown-install.js:1:202962
Removing intrinsics.%MapPrototype%.getOrInsertComputed lockdown-install.js:1:202962
Removing intrinsics.%WeakMapPrototype%.getOrInsert lockdown-install.js:1:202962
Removing intrinsics.%WeakMapPrototype%.getOrInsertComputed lockdown-install.js:1:202962
Removing intrinsics.%DatePrototype%.toTemporalInstant lockdown-install.js:1:202962
XHRPOST
http://192.168.1.50:3000/api/v1/models/model/access/update
[HTTP/1.1 404 Not Found 6ms]
(The SES/lockdown messages are unrelated browser extension output.)

Additional Information

After upgrading to v0.8.0, changing a model's access control (e.g., from Private to Public) via the Admin Panel produces an [object Object] error toast notification. The new access control UI introduced in #21277 sends the literal string "model" as the model ID in the API request instead of the actual model identifier, resulting in a 404 response that is displayed as [object Object] in the toast.

Originally created by @ahgray on GitHub (Feb 13, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/21377 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.8.0 ### Ollama Version (if applicable) n/a ### Operating System Ubuntu 22.04 w/Docker ### Browser (if applicable) Firefox 147 also reproduced on Chrome ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior The model's access control should update successfully and display a success toast notification. ### Actual Behavior An [object Object] error toast appears. The access control change does not persist — refreshing the page shows the model retains its original access control setting. ### Steps to Reproduce Log in as an admin user. Navigate to Admin Panel → Settings → Models. Click the edit (pencil) icon on any model. Change the Access Control dropdown from Private to Public (or any other change). Observe the [object Object] error toast in the top-right corner. ### Logs & Screenshots Browser Console Output The browser Network tab reveals the root cause: XHRPOST http://10.0.7.114:3000/api/v1/models/model/access/update [HTTP/1.1 404 Not Found 6ms] Status: 404 Not Found The URL contains the literal string model where the actual model ID should be (e.g., it should be /api/v1/models/gpt-4o/access/update or /api/v1/models/llama3:latest/access/update). The frontend component is passing a hardcoded or incorrectly-bound variable to the API call instead of the selected model's actual ID. The 404 JSON response ({"detail": "Not Found"}) is then displayed as [object Object] in the toast, likely because the error handler calls something like toast.error(error) on the response object rather than extracting the string (e.g., toast.error(error.detail)). Full console output: SES Removing unpermitted intrinsics lockdown-install.js:1:203117 Removing intrinsics.%MapPrototype%.getOrInsert lockdown-install.js:1:202962 Removing intrinsics.%MapPrototype%.getOrInsertComputed lockdown-install.js:1:202962 Removing intrinsics.%WeakMapPrototype%.getOrInsert lockdown-install.js:1:202962 Removing intrinsics.%WeakMapPrototype%.getOrInsertComputed lockdown-install.js:1:202962 Removing intrinsics.%DatePrototype%.toTemporalInstant lockdown-install.js:1:202962 XHRPOST http://192.168.1.50:3000/api/v1/models/model/access/update [HTTP/1.1 404 Not Found 6ms] (The SES/lockdown messages are unrelated browser extension output.) ### Additional Information After upgrading to v0.8.0, changing a model's access control (e.g., from Private to Public) via the Admin Panel produces an [object Object] error toast notification. The new access control UI introduced in #21277 sends the literal string "model" as the model ID in the API request instead of the actual model identifier, resulting in a 404 response that is displayed as [object Object] in the toast.

GiteaMirror added the bug label 2026-05-05 22:23:50 -05:00

GiteaMirror closed this issue 2026-05-05 22:23:51 -05:00

GiteaMirror commented 2026-05-05 22:23:53 -05:00

Author

Owner

Copy Link

@Classic298 commented on GitHub (Feb 13, 2026):

cannot reproduce. do you have any error logs relating to the access control migration?

<!-- gh-comment-id:3898054300 --> @Classic298 commented on GitHub (Feb 13, 2026): cannot reproduce. do you have any error logs relating to the access control migration?

GiteaMirror commented 2026-05-05 22:23:54 -05:00

Author

Owner

Copy Link

@ahgray commented on GitHub (Feb 13, 2026):

nothing showing in the docker logs just the post request.
uvicorn.protocols.http.httptools_impl:send:483 - 10.0.7.56:62911 - "POST /api/v1/models/model/access/update HTTP/1.1" 404

Just tried it in Chrome with dev console and get the following. Not sure if this helps. Happy to provide additional info. Not sure whats needed.

index.ts:287 POST http://10.0.7.114:3000/api/v1/models/model/access/update 404 (Not Found)
window.fetch @ fetcher.js:76
g @ index.ts:287
onChange @ ModelEditor.svelte:349
me @ AccessControl.svelte:192
ot @ AccessControl.svelte:211
(anonymous) @ AccessControl.svelte:474
(anonymous) @ events.js:61
Mt @ shared.js:44
s @ events.js:60
handleMouseUp_ @ unknown

<!-- gh-comment-id:3898402966 --> @ahgray commented on GitHub (Feb 13, 2026): nothing showing in the docker logs just the post request. uvicorn.protocols.http.httptools_impl:send:483 - 10.0.7.56:62911 - "POST /api/v1/models/model/access/update HTTP/1.1" 404 Just tried it in Chrome with dev console and get the following. Not sure if this helps. Happy to provide additional info. Not sure whats needed. index.ts:287 POST http://10.0.7.114:3000/api/v1/models/model/access/update 404 (Not Found) window.fetch @ fetcher.js:76 g @ index.ts:287 onChange @ ModelEditor.svelte:349 me @ AccessControl.svelte:192 ot @ AccessControl.svelte:211 (anonymous) @ AccessControl.svelte:474 (anonymous) @ events.js:61 Mt @ shared.js:44 s @ events.js:60 handleMouseUp_ @ unknown

GiteaMirror commented 2026-05-05 22:23:56 -05:00

Author

Owner

Copy Link

@Classic298 commented on GitHub (Feb 13, 2026):

hmmm

<!-- gh-comment-id:3898409599 --> @Classic298 commented on GitHub (Feb 13, 2026):  hmmm

GiteaMirror commented 2026-05-05 22:23:57 -05:00

Author

Owner

Copy Link

@ahgray commented on GitHub (Feb 13, 2026):

Ok this is way over my head but I've been troubleshooting this with Claude 4.6 and I've been able to create a workspace model and update its permission and then manually change the task model with a curl command. So I think Claude might be onto something. Anyway below is the comment it suggested I provide. Like I said I'm way out of my league here so if this is just AI slop take it with a tablespoon of salt lol.

v0.8.0 Access Control Regression: Two Bugs from PR #21277 Migration

I've done extensive debugging on the access control issues introduced by the PR #21277 refactor and found two distinct bugs. Both stem from incomplete migration between the old access_control JSON column and the new access_grant table system.

---

Environment

• Version: v0.8.0 (Docker ghcr.io/open-webui/open-webui:cuda)
• Image SHA: b0ecd5d7101000fc1907043df386358b35ab4475efccec591bf7ba1805aabb81
• Database: SQLite (confirmed access_control column fully removed from model table, access_grant table present and functional)

---

Bug 1: Access Control UI Renders for Base/Connection Models → 404 → [object Object]

Steps to reproduce:

1. Have Ollama or OpenAI connection models (no workspace models needed)
2. Go to Admin Panel → Models
3. Change a base model's visibility dropdown from "Private" to "Public"
4. Observe [object Object] toast error

Root cause:
The Admin Panel renders the AccessControl component for all models, including base/connection models that have no corresponding row in the model database table. When the dropdown is changed, the frontend calls:

POST /api/v1/models/model/access/update
Body: {"id": "base-model-id", "access_grants": [...]}

The backend handler at routers/models.py:507-540 calls Models.get_model_by_id(), which returns None for base models (they don't exist in the model table), resulting in a 404. The frontend then displays the error object as [object Object] instead of a human-readable message.

Expected behavior: Either hide the access control UI for non-workspace models, or auto-create a model table row when access is modified on a base model.

---

Bug 2: Task Model Selector Rejects All Models — Legacy access_control Check on Removed Field

Steps to reproduce:

1. Go to Admin Panel → Settings → Interface
2. Under "Local Task Model" or "External Task Model", select any model
3. Observe toast error: "This model is not publicly available. Please select another model."
4. This happens for every model, including models that are correctly public via access_grant

Root cause:
src/lib/components/admin/Settings/Interface.svelte lines 155 and 190:

if (model?.access_control !== null) {
    toast.error('This model is not publicly available. Please select another model.');
}

PR #21277 removed the access_control column from the database and the API no longer returns this field on model objects. So model.access_control is always undefined, and in JavaScript:

undefined !== null  // → true (always)

Every model fails this check. The validation is dead code that now blocks all task model selection from the UI.

Confirmed: The database has no access_control column. The access_grant table works correctly — I have a workspace model with a valid public grant:

('372ef44e-...', 'model', 'qwentest', 'user', '*', 'read', 1771006100)

Yet the UI still rejects it because it checks a field that no longer exists.

Workaround: Set the task model via API, bypassing frontend validation:

# Fetch current config, update TASK_MODEL, push back
curl -s http://HOST:PORT/api/v1/tasks/config \
  -H "Authorization: Bearer API_KEY" | \
  python3 -c "
import sys, json
config = json.load(sys.stdin)
config['TASK_MODEL'] = 'your-model-id'
print(json.dumps(config))
" | curl -s http://HOST:PORT/api/v1/tasks/config/update \
  -H "Authorization: Bearer API_KEY" \
  -H "Content-Type: application/json" \
  -d @-

This works — the backend accepts it without issue.

---

Suggested Fixes

Bug 1:

• Option A: Don't render access control UI for models without a model table row
• Option B: Auto-create a model table row when access is first configured on a base model
• Also: Stringify the error object in the frontend toast handler

Bug 2:

• Remove the access_control !== null check entirely (admins should be able to select any model as a task model — see also #14172)
• Or replace it with a query against the access_grant table to check actual public status

Both bugs indicate the PR #21277 migration left some frontend code pointing at the old access_control field. A grep for access_control across the frontend source may reveal other similar references that need updating.

---

Related

• PR #21277 — Access control refactor (+2,992/−877 lines)
• Issue #14172 — Feature request to eliminate public requirement for task models
• Issue #19335 — Previous id() leak bug in model access control (v0.6.36, similar pattern)

<!-- gh-comment-id:3898723034 --> @ahgray commented on GitHub (Feb 13, 2026): Ok this is way over my head but I've been troubleshooting this with Claude 4.6 and I've been able to create a workspace model and update its permission and then manually change the task model with a curl command. So I think Claude might be onto something. Anyway below is the comment it suggested I provide. Like I said I'm way out of my league here so if this is just AI slop take it with a tablespoon of salt lol. ## v0.8.0 Access Control Regression: Two Bugs from PR #21277 Migration I've done extensive debugging on the access control issues introduced by the PR #21277 refactor and found two distinct bugs. Both stem from incomplete migration between the old `access_control` JSON column and the new `access_grant` table system. --- ### Environment - **Version:** v0.8.0 (Docker `ghcr.io/open-webui/open-webui:cuda`) - **Image SHA:** `b0ecd5d7101000fc1907043df386358b35ab4475efccec591bf7ba1805aabb81` - **Database:** SQLite (confirmed `access_control` column fully removed from `model` table, `access_grant` table present and functional) --- ### Bug 1: Access Control UI Renders for Base/Connection Models → 404 → `[object Object]` **Steps to reproduce:** 1. Have Ollama or OpenAI connection models (no workspace models needed) 2. Go to Admin Panel → Models 3. Change a base model's visibility dropdown from "Private" to "Public" 4. Observe `[object Object]` toast error **Root cause:** The Admin Panel renders the `AccessControl` component for **all** models, including base/connection models that have no corresponding row in the `model` database table. When the dropdown is changed, the frontend calls: ``` POST /api/v1/models/model/access/update Body: {"id": "base-model-id", "access_grants": [...]} ``` The backend handler at `routers/models.py:507-540` calls `Models.get_model_by_id()`, which returns `None` for base models (they don't exist in the `model` table), resulting in a 404. The frontend then displays the error object as `[object Object]` instead of a human-readable message. **Expected behavior:** Either hide the access control UI for non-workspace models, or auto-create a `model` table row when access is modified on a base model. --- ### Bug 2: Task Model Selector Rejects All Models — Legacy `access_control` Check on Removed Field **Steps to reproduce:** 1. Go to Admin Panel → Settings → Interface 2. Under "Local Task Model" or "External Task Model", select any model 3. Observe toast error: *"This model is not publicly available. Please select another model."* 4. This happens for **every** model, including models that are correctly public via `access_grant` **Root cause:** `src/lib/components/admin/Settings/Interface.svelte` lines 155 and 190: ```javascript if (model?.access_control !== null) { toast.error('This model is not publicly available. Please select another model.'); } ``` PR #21277 removed the `access_control` column from the database and the API no longer returns this field on model objects. So `model.access_control` is always `undefined`, and in JavaScript: ```javascript undefined !== null // → true (always) ``` **Every model fails this check.** The validation is dead code that now blocks all task model selection from the UI. **Confirmed:** The database has no `access_control` column. The `access_grant` table works correctly — I have a workspace model with a valid public grant: ``` ('372ef44e-...', 'model', 'qwentest', 'user', '*', 'read', 1771006100) ``` Yet the UI still rejects it because it checks a field that no longer exists. **Workaround:** Set the task model via API, bypassing frontend validation: ```bash # Fetch current config, update TASK_MODEL, push back curl -s http://HOST:PORT/api/v1/tasks/config \ -H "Authorization: Bearer API_KEY" | \ python3 -c " import sys, json config = json.load(sys.stdin) config['TASK_MODEL'] = 'your-model-id' print(json.dumps(config)) " | curl -s http://HOST:PORT/api/v1/tasks/config/update \ -H "Authorization: Bearer API_KEY" \ -H "Content-Type: application/json" \ -d @- ``` This works — the backend accepts it without issue. --- ### Suggested Fixes **Bug 1:** - Option A: Don't render access control UI for models without a `model` table row - Option B: Auto-create a `model` table row when access is first configured on a base model - Also: Stringify the error object in the frontend toast handler **Bug 2:** - Remove the `access_control !== null` check entirely (admins should be able to select any model as a task model — see also #14172) - Or replace it with a query against the `access_grant` table to check actual public status Both bugs indicate the PR #21277 migration left some frontend code pointing at the old `access_control` field. A grep for `access_control` across the frontend source may reveal other similar references that need updating. --- ### Related - PR #21277 — Access control refactor (+2,992/−877 lines) - Issue #14172 — Feature request to eliminate public requirement for task models - Issue #19335 — Previous `id()` leak bug in model access control (v0.6.36, similar pattern)

GiteaMirror commented 2026-05-05 22:23:57 -05:00

Author

Owner

Copy Link

@tjbck commented on GitHub (Feb 13, 2026):

Should be addressed in dev!

<!-- gh-comment-id:3899363652 --> @tjbck commented on GitHub (Feb 13, 2026): Should be addressed in dev!

GiteaMirror commented 2026-05-05 22:23:58 -05:00

Author

Owner

Copy Link

@ahgray commented on GitHub (Feb 13, 2026):

Awesome. Hopefully the information was helpful.

<!-- gh-comment-id:3899636075 --> @ahgray commented on GitHub (Feb 13, 2026): Awesome. Hopefully the information was helpful.

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

dev

v0.9.2

v0.9.1

v0.9.0

v0.8.12

v0.8.11

v0.8.10

v0.8.9

v0.8.8

v0.8.7

v0.8.6

v0.8.5

v0.8.4

v0.8.3

v0.8.2

v0.8.1

v0.8.0

v0.7.2

v0.7.1

v0.7.0

v0.6.43

v0.6.42

v0.6.41

v0.6.40

v0.6.39

v0.6.38

v0.6.37

v0.6.36

v0.6.35

v0.6.34

v0.6.33

v0.6.32

v0.6.31

v0.6.30

v0.6.29

v0.6.28

v0.6.27

v0.6.26

v0.6.25

v0.6.24

v0.6.23

v0.6.22

v0.6.21

v0.6.20

v0.6.19

v0.6.18

v0.6.17

v0.6.16

v0.6.15

v0.6.14

v0.6.13

v0.6.12

v0.6.11

v0.6.10

v0.6.9

v0.6.8

v0.6.7

v0.6.6

v0.6.5

v0.6.4

v0.6.3

v0.6.2

v0.6.1

v0.6.0

v0.5.20

v0.5.19

v0.5.18

v0.5.17

v0.5.16

v0.5.15

v0.5.14

v0.5.13

v0.5.12

v0.5.11

v0.5.10

v0.5.9

v0.5.8

v0.5.7

v0.5.6

v0.5.5

v0.5.4

v0.5.3

v0.5.2

v0.5.1

v0.5.0

v0.4.8

v0.4.7

v0.4.6

v0.4.5

v0.4.4

v0.4.3

v0.4.2

v0.4.1

v0.4.0

v0.3.35

v0.3.34

v0.3.33

v0.3.32

v0.3.31

v0.3.30

v0.3.29

v0.3.28

v0.3.27

v0.3.26

v0.3.25

v0.3.24

v0.3.23

v0.3.22

v0.3.21

v0.3.20

v0.3.19

v0.3.18

v0.3.17

v0.3.16

v0.3.15

v0.3.14

v0.3.13

v0.3.12

v0.3.11

v0.3.10

v0.3.9

v0.3.8

v0.3.7

v0.3.6

v0.3.5

v0.3.4

v0.3.3

v0.3.2

v0.3.1

v0.3.0

v0.2.5

v0.2.4

v0.2.3

v0.2.2

v0.2.1

v0.2.0

v0.1.125

v0.1.124

v0.1.123

v0.1.122

v0.1.121

v0.1.120

v0.1.119

v0.1.118

v0.1.117

v0.1.116

v0.1.115

v0.1.114

v0.1.113

v0.1.112

v0.1.111

v0.1.110

v0.1.109

v0.1.108

v0.1.107

v0.1.106

v0.1.105

v0.1.104

v0.1.103

v0.1.102

Labels

Clear labels

bug

confirmed

confirmed issue

core

documentation

enhancement

good first issue

help wanted

non-core

pull-request

Mirrored from GitHub Pull Request

python

question

testing wanted

No Label bug

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

GiteaMirror ninjasurge

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#58125