[GH-ISSUE #16625] issue: ENABLE_ADMIN_CHAT_ACCESS does not remove "export Database" and "Export all chats" functionality from admin ui #17980

Closed
opened 2026-04-19 23:53:09 -05:00 by GiteaMirror · 10 comments
Owner

Originally created by @dwt on GitHub (Aug 14, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/16625

Check Existing Issues

  • I have searched the existing issues and discussions.
  • I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.18

Ollama Version (if applicable)

0.11.2

Operating System

MacOS 15.6 (24G84)

Browser (if applicable)

Safari 18.6

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

When setting the einvironment variable ENABLE_ADMIN_CHAT_ACCESS, the admin settings should not provide any way to download individual or collective user chats.

Actual Behavior

When setting the einvironment variable ENABLE_ADMIN_CHAT_ACCESS it is no longer possible to view individual users chat history in the admin -> users view. But it is still possible to switch to the database admin view and download all chats from all users, as well as the full database, which also gets those.

Image

Steps to Reproduce

  1. Install via Helm-Chart https://open-webui.github.io/helm-charts
  2. Enable setting `ENABLE_ADMIN_CHAT_ACCESS=false, in the values.yaml like this: (excerpt)
    extraEnvVars:
      - name: ENABLE_ADMIN_CHAT_ACCESS
        value: "false"
    
  3. Redeploy open-webui
  4. Navigate to Admin -> Settings -> Database

Logs & Screenshots

Browser logs, likely irrelevant

[Error] Unhandled Promise Rejection: TypeError: undefined is not a function (near '...M of w...')
	(anonyme Funktion) (2.PTIxhjRu.js:2814:729544)
	(anonyme Funktion) (2.PTIxhjRu.js:2814:729619)
	(anonyme Funktion) (2.PTIxhjRu.js:2814:729620)
	(anonyme Funktion) (2.PTIxhjRu.js:2814:729687)
	Modulcode (2.PTIxhjRu.js:2814:746127)
Image

Additional Information

This bug is quite annoying for us. We would like to deploy this in our company as an experiment to prove that Self-Hosting Models is a viable strategy. For that we want Admins, that can add and remove users as needed, but they should never be able to view the chats from users.

The setting and its description looks quite promising. Indeed it seems to remove user chat access from the UI - but not quite thorough.

Originally created by @dwt on GitHub (Aug 14, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/16625 ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.18 ### Ollama Version (if applicable) 0.11.2 ### Operating System MacOS 15.6 (24G84) ### Browser (if applicable) Safari 18.6 ### 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 When setting the einvironment variable `ENABLE_ADMIN_CHAT_ACCESS`, the admin settings should not provide any way to download individual or collective user chats. ### Actual Behavior When setting the einvironment variable `ENABLE_ADMIN_CHAT_ACCESS` it is no longer possible to view individual users chat history in the admin -> users view. But it is still possible to switch to the database admin view and download all chats from all users, as well as the full database, which also gets those. <img width="746" height="267" alt="Image" src="https://github.com/user-attachments/assets/ccb0822a-adce-40cf-9398-8427f8c9f713" /> ### Steps to Reproduce 1. Install via Helm-Chart https://open-webui.github.io/helm-charts 2. Enable setting `ENABLE_ADMIN_CHAT_ACCESS=false, in the values.yaml like this: (excerpt) ```yaml extraEnvVars: - name: ENABLE_ADMIN_CHAT_ACCESS value: "false" ``` 3. Redeploy open-webui 4. Navigate to Admin -> Settings -> Database ### Logs & Screenshots Browser logs, likely irrelevant ```log [Error] Unhandled Promise Rejection: TypeError: undefined is not a function (near '...M of w...') (anonyme Funktion) (2.PTIxhjRu.js:2814:729544) (anonyme Funktion) (2.PTIxhjRu.js:2814:729619) (anonyme Funktion) (2.PTIxhjRu.js:2814:729620) (anonyme Funktion) (2.PTIxhjRu.js:2814:729687) Modulcode (2.PTIxhjRu.js:2814:746127) ``` <img width="746" height="267" alt="Image" src="https://github.com/user-attachments/assets/ccb0822a-adce-40cf-9398-8427f8c9f713" /> ### Additional Information This bug is quite annoying for us. We would like to deploy this in our company as an experiment to prove that Self-Hosting Models is a viable strategy. For that we want Admins, that can add and remove users as needed, but they should never be able to view the chats from users. The setting and its description looks quite promising. Indeed it seems to remove user chat access from the UI - but not quite thorough.
GiteaMirror added the bug label 2026-04-19 23:53:09 -05:00
Author
Owner

@Classic298 commented on GitHub (Aug 14, 2025):

Expected Behavior: When setting the einvironment variable ENABLE_ADMIN_CHAT_ACCESS, the admin settings should not provide any way to download individual or collective user chats.

Mind me asking, why would you expect that? The docs clearly say that this env var only disables direct chat access to individual users by hiding the button to allow you to access chats of individual users

But it is still possible to switch to the database admin view and download all chats from all users, as well as the full database, which also gets those.

And you can also just access the database file, which you surely have access to as an admin, or connect to the database (postgreSQL) and access the data

For that we want Admins, that can add and remove users as needed, but they should never be able to view the chats from users.

they can't - unless they access the database, and they can always do that - usually admins have access to the server, no? Administrators need access to the server for updating open webui and other tasks. So they could always access the database and theoretically read chats.

<!-- gh-comment-id:3188857634 --> @Classic298 commented on GitHub (Aug 14, 2025): >Expected Behavior: When setting the einvironment variable ENABLE_ADMIN_CHAT_ACCESS, the admin settings should not provide any way to download individual or collective user chats. Mind me asking, why would you expect that? The docs clearly say that this env var only disables direct chat access to individual users by hiding the button to allow you to access chats of individual users > But it is still possible to switch to the database admin view and download all chats from all users, as well as the full database, which also gets those. And you can also just access the database file, which you surely have access to as an admin, or connect to the database (postgreSQL) and access the data > For that we want Admins, that can add and remove users as needed, but they should never be able to view the chats from users. they can't - unless they access the database, and they can always do that - usually admins have access to the server, no? Administrators need access to the server for updating open webui and other tasks. So they could always access the database and theoretically read chats.
Author
Owner

@tjbck commented on GitHub (Aug 14, 2025):

@dwt as a work around for this, you can and should use postgres to disable those two buttons.

<!-- gh-comment-id:3189831683 --> @tjbck commented on GitHub (Aug 14, 2025): @dwt as a work around for this, you can and should use postgres to disable those two buttons.
Author
Owner

@dwt commented on GitHub (Aug 15, 2025):

@Classic298 Why would I expect this? Because having admin privileges in the Open WebUI can easily be separated from having technical access to the runtime and database, and thus makes a a lot of difference for privilege separation. I also wouldn't expect this to be hard, and I would be happy to provide a patch to change this behavior.

So: No, Application Admins do not need to have access to the server or database. That might be often the case, but there is no necessity to merge these two roles from the permission level.

<!-- gh-comment-id:3190727523 --> @dwt commented on GitHub (Aug 15, 2025): @Classic298 Why would I expect this? Because having admin privileges in the Open WebUI can easily be separated from having technical access to the runtime and database, and thus makes a a lot of difference for privilege separation. I also wouldn't expect this to be hard, and I would be happy to provide a patch to change this behavior. So: No, Application Admins do not need to have access to the server or database. That might be often the case, but there is no necessity to merge these two roles from the permission level.
Author
Owner

@dwt commented on GitHub (Aug 15, 2025):

Going for Postgress is a nice suggestion and I'll check that out.

I would still argue that removing those two handlers when that setting is set should be an easy win for this setting to make more sense and improve Open WebUI for all users.

Also, I'd be willing to collaborate to fix this.

<!-- gh-comment-id:3190729656 --> @dwt commented on GitHub (Aug 15, 2025): Going for Postgress is a nice suggestion and I'll check that out. I would still argue that removing those two handlers when that setting is set should be an easy win for this setting to make more sense and improve Open WebUI for all users. Also, I'd be willing to collaborate to fix this.
Author
Owner

@Classic298 commented on GitHub (Aug 15, 2025):

Well in that case, this is not an issue or bug as you labeled it, but a feature request? Since the environment variable is working as expected.

But sure feel free to propose a PR, i can do a code review if you like and we can collaborate on a docs change.

<!-- gh-comment-id:3190946737 --> @Classic298 commented on GitHub (Aug 15, 2025): Well in that case, this is not an issue or bug as you labeled it, but a feature request? Since the environment variable is working as expected. But sure feel free to propose a PR, i can do a code review if you like and we can collaborate on a docs change.
Author
Owner

@tjbck commented on GitHub (Aug 17, 2025):

ENABLE_ADMIN_EXPORT env var is already present.

<!-- gh-comment-id:3194008969 --> @tjbck commented on GitHub (Aug 17, 2025): `ENABLE_ADMIN_EXPORT` env var is already present.
Author
Owner

@Classic298 commented on GitHub (Aug 17, 2025):

@dwt @tjbck i will modify the documentation and move this env var more to the enable admin chat access and modify the description of this env var

<!-- gh-comment-id:3194376575 --> @Classic298 commented on GitHub (Aug 17, 2025): @dwt @tjbck i will modify the documentation and move this env var more to the enable admin chat access and modify the description of this env var
Author
Owner

@dwt commented on GitHub (Aug 18, 2025):

Thanks! That Variable is indeed what I wanted.

What do you think about making ENABLE_ADMIN_EXPORT default to False, when ENABLE_ADMIN_CHAT_ACCESS is set to false?

<!-- gh-comment-id:3195568083 --> @dwt commented on GitHub (Aug 18, 2025): Thanks! That Variable is indeed what I wanted. What do you think about making ENABLE_ADMIN_EXPORT default to False, when ENABLE_ADMIN_CHAT_ACCESS is set to false?
Author
Owner

@Classic298 commented on GitHub (Aug 18, 2025):

@dwt so what you mean is to automatically set another (technically unrelated) env var to another value if one env var is set to false?

I know for a fact that this behaviour IS PRESENT somewhere for other env vars, but there, it is technically necessary otherwise some features wouldn't work at all.

Here, we are talking about two technically different env vars that do different things.
I am not sure it'd be smart to interconnect them like this, even if properly documented.

You can open a PR if you like and let tim decide.

<!-- gh-comment-id:3197259492 --> @Classic298 commented on GitHub (Aug 18, 2025): @dwt so what you mean is to automatically set another (technically unrelated) env var to another value if one env var is set to false? I know for a fact that this behaviour IS PRESENT somewhere for other env vars, but there, it is technically necessary otherwise some features wouldn't work at all. Here, we are talking about two technically different env vars that do different things. I am not sure it'd be smart to interconnect them like this, even if properly documented. You can open a PR if you like and let tim decide.
Author
Owner

@dwt commented on GitHub (Aug 19, 2025):

@Classic298, @tjbck : I opened a pull request with the changes we talked about here at #16738. I would welcome your feedback and help to get this mergeable.

<!-- gh-comment-id:3202062809 --> @dwt commented on GitHub (Aug 19, 2025): @Classic298, @tjbck : I opened a pull request with the changes we talked about here at #16738. I would welcome your feedback and help to get this mergeable.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#17980