mirror of
https://github.com/open-webui/open-webui.git
synced 2026-08-02 06:39:02 -05:00
[GH-ISSUE #16625] issue: ENABLE_ADMIN_CHAT_ACCESS does not remove "export Database" and "Export all chats" functionality from admin ui #17980
Reference in New Issue
Block a user
Originally created by @dwt on GitHub (Aug 14, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/16625
Check Existing Issues
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
README.md.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_ACCESSit 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.Steps to Reproduce
Logs & Screenshots
Browser logs, likely irrelevant
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.
@Classic298 commented on GitHub (Aug 14, 2025):
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
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
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.
@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.
@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.
@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.
@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.
@tjbck commented on GitHub (Aug 17, 2025):
ENABLE_ADMIN_EXPORTenv var is already present.@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
@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?
@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.
@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.