feat: User Permission Toggle for RAG Document Access #440

New Issue

Closed

opened 2025-11-11 14:21:26 -06:00 by GiteaMirror · 6 comments

GiteaMirror commented 2025-11-11 14:21:26 -06:00

Owner

Copy Link

Originally created by @silentoplayz on GitHub (Mar 8, 2024).

Is your feature request related to a problem? Please describe.
Yes, the current options for user account permissions in the Users tab of the Admin Settings in the Admin Panel are lacking. Specifically, while users can call upon admin uploaded documents and ask questions about them in the context of Retrieval-Augmented Generation (RAG), there is no user permission toggle to control access to these documents for the RAG feature on user accounts. This could pose a potential security risk to unaware admins about this potential leakage of their vital information.

Describe the solution you'd like
I would like a user permission toggle for admin uploaded document access within the Users tab of the Admin Settings in the Admin Panel. This will allow admins to better control and secure their uploaded documents from potential leakage or unauthorized access.

Describe alternatives you've considered
N/A

Additional context
Adding this feature will provide consistency in managing user permissions across core features of Open WebUI. Additionally, it will improve the security of admin uploaded documents and provide admins with more control over their information.

Benefits

• Security: By adding a user permission toggle for document access in RAG, admins can better control and secure their uploaded documents from potential leakage or unauthorized access.
• Consistency: Consistent user experience for managing user permissions across core features of Open WebUI.

Implementation

• Add a new user permission toggle for admin uploaded document access within the Users tab of the Admin Settings in the Admin Panel.
• The proposed name for this toggle is Allow RAG Document Access.
• Marginalizing the ease of use benefit to a lesser degree, as restricting access to documents per user on a per user level could be a potential future enhancement.

Originally created by @silentoplayz on GitHub (Mar 8, 2024). **Is your feature request related to a problem? Please describe.** Yes, the current options for user account permissions in the `Users` tab of the `Admin Settings` in the `Admin Panel` are lacking. Specifically, while users can call upon admin uploaded documents and ask questions about them in the context of Retrieval-Augmented Generation (RAG), there is no user permission toggle to control access to these documents for the RAG feature on user accounts. This could pose a potential security risk to unaware admins about this potential leakage of their vital information. **Describe the solution you'd like** I would like a user permission toggle for admin uploaded document access within the `Users` tab of the `Admin Settings` in the `Admin Panel`. This will allow admins to better control and secure their uploaded documents from potential leakage or unauthorized access. **Describe alternatives you've considered** N/A **Additional context** Adding this feature will provide consistency in managing user permissions across core features of Open WebUI. Additionally, it will improve the security of admin uploaded documents and provide admins with more control over their information. **Benefits** * Security: By adding a user permission toggle for document access in RAG, admins can better control and secure their uploaded documents from potential leakage or unauthorized access. * Consistency: Consistent user experience for managing user permissions across core features of Open WebUI. **Implementation** * Add a new user permission toggle for admin uploaded document access within the `Users` tab of the `Admin Settings` in the `Admin Panel`. * The proposed name for this toggle is `Allow RAG Document Access`. * *Marginalizing the ease of use benefit to a lesser degree, as restricting access to documents per user on a per user level could be a potential future enhancement.* 

GiteaMirror added the enhancementcore labels 2025-11-11 14:21:26 -06:00

GiteaMirror closed this issue 2025-11-11 14:21:26 -06:00

GiteaMirror commented 2025-11-11 14:21:27 -06:00

Author

Owner

Copy Link

@silentoplayz commented on GitHub (Apr 4, 2024):

Alternative Solution(s)

Two potential solutions to consider are:

1. Add a "Private" or "Confidential" designation to documents in the Documents tab, which would restrict access to those documents to only certain users or groups of users. This could be implemented by adding a new field to the document metadata that specifies the level of access allowed for the document.

For example, a new "Access Level" field could be added to the document metadata with the following options:

• Public: Anyone can view and interact with the document.
• Private: Only specific users or groups of users can view and interact with the document.
• Confidential: Only the document owner can view and interact with the document.

Admins could then set the Access Level field for each document as they upload it, allowing them to restrict access to documents as needed.

2. Another potential solution could be to implement a private document sharing feature where users can toggle a lock/unlock icon next to each document in the Documents tab. This would allow admins to restrict access to documents on a per-document basis, while still allowing for easy access and collaboration on documents within the Open WebUI community.

Implementation

Alternative 1

• Add a new field to the document metadata for Access Level.
• Provide options for Access Level: Public, Private, and Confidential.
• Allow admins to set the Access Level for each document as they upload it.
• Restrict access to documents based on the Access Level setting.

Alternative 2

• Add a lock/unlock icon next to each document in the Documents tab in the chat navbar.
• When a user clicks on the lock icon, a dialog box could appear asking the user to confirm that they want to restrict access to the document.
• Once a document is locked, only users with explicit permission would be able to access it.
• Users with permission to access a locked document could be managed in the Users tab of the Admin Settings in the Admin Panel.

These alternative solutions would provide the following benefits:

• Improved security: Restricting access to documents would reduce the risk of unauthorized access or document leakage.
• Fine-grained control: Admins would have the ability to control access to documents on a per-document basis, providing more control and flexibility.

@silentoplayz commented on GitHub (Apr 4, 2024): ## **Alternative Solution(s)** Two potential solutions to consider are: 1. Add a "Private" or "Confidential" designation to documents in the Documents tab, which would restrict access to those documents to only certain users or groups of users. This could be implemented by adding a new field to the document metadata that specifies the level of access allowed for the document. For example, a new "Access Level" field could be added to the document metadata with the following options: * Public: Anyone can view and interact with the document. * Private: Only specific users or groups of users can view and interact with the document. * Confidential: Only the document owner can view and interact with the document. Admins could then set the Access Level field for each document as they upload it, allowing them to restrict access to documents as needed. 2. Another potential solution could be to implement a private document sharing feature where users can toggle a lock/unlock icon next to each document in the Documents tab. This would allow admins to restrict access to documents on a per-document basis, while still allowing for easy access and collaboration on documents within the Open WebUI community. ## Implementation **Alternative 1** * Add a new field to the document metadata for Access Level. * Provide options for Access Level: Public, Private, and Confidential. * Allow admins to set the Access Level for each document as they upload it. * Restrict access to documents based on the Access Level setting. **Alternative 2** * Add a lock/unlock icon next to each document in the Documents tab in the chat navbar. * When a user clicks on the lock icon, a dialog box could appear asking the user to confirm that they want to restrict access to the document. * Once a document is locked, only users with explicit permission would be able to access it. * Users with permission to access a locked document could be managed in the Users tab of the Admin Settings in the Admin Panel. These alternative solutions would provide the following benefits: * Improved security: Restricting access to documents would reduce the risk of unauthorized access or document leakage. * Fine-grained control: Admins would have the ability to control access to documents on a per-document basis, providing more control and flexibility.

GiteaMirror commented 2025-11-11 14:21:27 -06:00

Author

Owner

Copy Link

@wenzel-felix commented on GitHub (Apr 11, 2024):

Hi, maybe another idea in addition to @Silentoplayz proposed solutions:

Alternative 3:

• Add "workspaces" in the UI for each chat which map to a specific metadata label in ChromaDB
• Any user can create a "workspace" and share it with other users (admins can create global "workspaces", automatically shared with all users - which could be used to dump company-wide knowledge bases)
• Only the original creator can delete a "workspace"
• Users select the workspaces relevant to the chats when starting a new one

Benefits:

• Security: PoLP - decentralized management of data and access (teams manage their data and the admin has no power over any documents not owned by him)
• Flexibility for the users to share documents freely

@wenzel-felix commented on GitHub (Apr 11, 2024): Hi, maybe another idea in addition to @Silentoplayz proposed solutions: **Alternative 3:** * Add "workspaces" in the UI for each chat which map to a specific metadata label in ChromaDB * Any user can create a "workspace" and share it with other users (admins can create global "workspaces", automatically shared with all users - which could be used to dump company-wide knowledge bases) * Only the original creator can delete a "workspace" * Users select the workspaces relevant to the chats when starting a new one Benefits: * Security: PoLP - decentralized management of data and access (teams manage their data and the admin has no power over any documents not owned by him) * Flexibility for the users to share documents freely

GiteaMirror commented 2025-11-11 14:21:27 -06:00

Author

Owner

Copy Link

@silentoplayz commented on GitHub (Apr 11, 2024):

Alternative 4

Introduce a document access approval system that triggers a notification to the document owner(s) or an assigned delegate when a user requests access to their documents within RAG.

Features:

• Request and Approval: A user can request access to a specific document, generating an approval request for the document owner(s) or a designated delegate.
• Notification system: Document owners receive a request notification, prompting them to review and either approve or deny the access request.
• Approval expiration: Implement a time limit for approvals, prompting users to review and respond to pending requests.
• Approval revocation: Allow document owners or delegates to revoke previously granted access.

Benefits:

• Enhanced security: Requesting and granting access to documents on a case-by-case basis reduces the risk of unauthorized access or document leakage.
• Increased accountability: By tracking access requests and their outcomes, admins and document owners have an overview of who accessed which documents and when.
• User convenience: The request and approval system simplifies the process of sharing documents, removing the need for managing individual access settings for each user.

I'm all ears for more alternative solutions and even a combination of proposed features already. Let's keep this issue open and lively, shall we?

@silentoplayz commented on GitHub (Apr 11, 2024): ### **Alternative 4** Introduce a document access approval system that triggers a notification to the document owner(s) or an assigned delegate when a user requests access to their documents within RAG. Features: - Request and Approval: A user can request access to a specific document, generating an approval request for the document owner(s) or a designated delegate. - Notification system: Document owners receive a request notification, prompting them to review and either approve or deny the access request. - Approval expiration: Implement a time limit for approvals, prompting users to review and respond to pending requests. - Approval revocation: Allow document owners or delegates to revoke previously granted access. Benefits: - Enhanced security: Requesting and granting access to documents on a case-by-case basis reduces the risk of unauthorized access or document leakage. - Increased accountability: By tracking access requests and their outcomes, admins and document owners have an overview of who accessed which documents and when. - User convenience: The request and approval system simplifies the process of sharing documents, removing the need for managing individual access settings for each user. I'm all ears for more alternative solutions and even a combination of proposed features already. Let's keep this issue open and lively, shall we?

GiteaMirror commented 2025-11-11 14:21:27 -06:00

Author

Owner

Copy Link

@silentoplayz commented on GitHub (Apr 11, 2024):

Because why stop there?

Alternative 5: Combined Document Access Control System (This should be a new issue at this point, lol)

Description: This solution combines together and refines the best aspects of the previous proposed alternatives and solutions in order to provide a comprehensive and user-oriented document management system that addresses access control, security, and user convenience.

Components:

1. Document Access Control

• Introduce a new field to the document metadata for Access Level, including: Public, Approval Required, and Confidential.
• When the Access Level is set to "Approval Required", users will be prompted to request access.
• Document owners or designated delegates can grant or deny access to documents based on the request.
• Approval requests have an expiration time limit, encouraging timely responses.
• Document owners or designated delegates can revoke previously granted access.

2. Workspaces

• Add "workspaces" in the UI for each chat, mapping to ChromaDB collections.
• Admins can create workspaces and share them with other users, allowing for flexible and secure sharing of documents.
• Admins and users can determine the access level for each workspace they create, either Public, Approval Required, or Confidential.
• Only the original creator can delete a workspace.
• Users can select workspaces relevant to the chats when starting a new one.

3. Document Access Approval System

• Implement a notification system for document owners or designated delegates to receive and respond to access requests.
• Approval expiration and revocation features are integrated within the document management system.

4. Private Document Sharing

• Implement a private document sharing feature where users can toggle a lock/unlock icon next to each document in the Documents tab.
• This enables admins to restrict access to documents on a per-document basis while maintaining easy access and collaboration for documents within the Open WebUI community.

Benefits:

1. Improved security: The combined solution results in a more secure system as a whole, reducing the risk of unauthorized access or document leakage.
2. Flexibility for users: Users have the ability to control access to documents on a per-document basis, providing more control and flexibility.
3. Decentralized management: By introducing workspaces, users can manage their data and have better control over their information.
4. Scalability: Global "workspaces" created by admins enable organizations to share company-wide knowledge bases and resources with all users.
5. Accountability: Document access requests and their outcomes enable admins and document owners to monitor who accessed which documents and when.
6. User convenience: The combined features simplify the process of sharing documents and managing access levels, while also maintaining security and scalability.

Implementation:

1. Introduce a new field to the document metadata for Access Level and implement the corresponding functionality.
2. Implement workspaces within the UI, along with user interface components for sharing, revoking, and adjusting access levels for documents and workspaces.
3. Develop a notification system for document owners or designated delegates to receive and respond to access requests.
4. Integrate approval expiration and revocation features within the document management system.
5. Implement a private document sharing feature with a lock/unlock icon in the Documents tab.

This combined solution offers improved security, flexibility, and user convenience, as well as decentralization of document management, accountability, and scalability.

TL;DR: The proposed solution is a comprehensive document management system that combines various aspects to address access control, security, and user convenience. It includes document access control with three levels (Public, Approval Required, and Confidential), workspaces for secure sharing, a document approval system for notifications, private document sharing, and a lock/unlock icon in the Documents tab. This system offers improved security, flexibility, decentralization, accountability, scalability, and user convenience. Implementation involves adding an Access Level field to documents, creating workspaces within the UI, developing a notification system, integrating approval expiration and revocation features, and implementing private document sharing with a lock/unlock icon in the Documents tab.

@silentoplayz commented on GitHub (Apr 11, 2024): # Because why stop there? ### Alternative 5: Combined Document Access Control System (This should be a new issue at this point, lol) **Description:** This solution combines together and refines the best aspects of the previous proposed alternatives and solutions in order to provide a comprehensive and user-oriented document management system that addresses access control, security, and user convenience. **Components:** **1. Document Access Control** - Introduce a new field to the document metadata for Access Level, including: Public, Approval Required, and Confidential. - When the Access Level is set to "Approval Required", users will be prompted to request access. - Document owners or designated delegates can grant or deny access to documents based on the request. - Approval requests have an expiration time limit, encouraging timely responses. - Document owners or designated delegates can revoke previously granted access. **2. Workspaces** - Add "workspaces" in the UI for each chat, mapping to ChromaDB collections. - Admins can create workspaces and share them with other users, allowing for flexible and secure sharing of documents. - Admins and users can determine the access level for each workspace they create, either Public, Approval Required, or Confidential. - Only the original creator can delete a workspace. - Users can select workspaces relevant to the chats when starting a new one. **3. Document Access Approval System** - Implement a notification system for document owners or designated delegates to receive and respond to access requests. - Approval expiration and revocation features are integrated within the document management system. **4. Private Document Sharing** - Implement a private document sharing feature where users can toggle a lock/unlock icon next to each document in the Documents tab. - This enables admins to restrict access to documents on a per-document basis while maintaining easy access and collaboration for documents within the Open WebUI community. **Benefits:** 1. Improved security: The combined solution results in a more secure system as a whole, reducing the risk of unauthorized access or document leakage. 2. Flexibility for users: Users have the ability to control access to documents on a per-document basis, providing more control and flexibility. 3. Decentralized management: By introducing workspaces, users can manage their data and have better control over their information. 4. Scalability: Global "workspaces" created by admins enable organizations to share company-wide knowledge bases and resources with all users. 5. Accountability: Document access requests and their outcomes enable admins and document owners to monitor who accessed which documents and when. 6. User convenience: The combined features simplify the process of sharing documents and managing access levels, while also maintaining security and scalability. **Implementation:** 1. Introduce a new field to the document metadata for Access Level and implement the corresponding functionality. 2. Implement workspaces within the UI, along with user interface components for sharing, revoking, and adjusting access levels for documents and workspaces. 3. Develop a notification system for document owners or designated delegates to receive and respond to access requests. 4. Integrate approval expiration and revocation features within the document management system. 5. Implement a private document sharing feature with a lock/unlock icon in the Documents tab. This combined solution offers improved security, flexibility, and user convenience, as well as decentralization of document management, accountability, and scalability. ### TL;DR: The proposed solution is a comprehensive document management system that combines various aspects to address access control, security, and user convenience. It includes document access control with three levels (Public, Approval Required, and Confidential), workspaces for secure sharing, a document approval system for notifications, private document sharing, and a lock/unlock icon in the Documents tab. This system offers improved security, flexibility, decentralization, accountability, scalability, and user convenience. Implementation involves adding an Access Level field to documents, creating workspaces within the UI, developing a notification system, integrating approval expiration and revocation features, and implementing private document sharing with a lock/unlock icon in the Documents tab.

GiteaMirror commented 2025-11-11 14:21:28 -06:00

Author

Owner

Copy Link

@jacobsamo commented on GitHub (Apr 28, 2024):

Adding to this I would like to include some possible mockups of the UI.

Admin configuration

As suggested by @Silentoplayz earilier, the ability to toggle on or off RAG for users

Which would show the documents tab in sidebar, looking something like this:

Documents page, adding documents, securing documents

The change of access control in adding of doucuments may look something like this:

I have added an extra type which is Private which would allow users to share specific documents with users or just leave it as their own giving the ability to share if you choose

Notes

Excaildraw documents for those interested: https://excalidraw.com/#json=NXy7y5Tots5SZzegjjsmJ,J-7YC24eiRVPaDVc-37ggQ

I will continue to update this comment with more mock ups as i go, as I haven't covered all possible changes just yet. Please share any thoughts or possible changes

@jacobsamo commented on GitHub (Apr 28, 2024): Adding to this I would like to include some possible mockups of the UI. ### Admin configuration As suggested by @Silentoplayz earilier, the ability to toggle on or off RAG for users  Which would show the documents tab in sidebar, looking something like this:  ### Documents page, adding documents, securing documents The change of access control in adding of doucuments may look something like this:  I have added an extra type which is `Private` which would allow users to share specific documents with users or just leave it as their own giving the ability to share if you choose ### Notes Excaildraw documents for those interested: https://excalidraw.com/#json=NXy7y5Tots5SZzegjjsmJ,J-7YC24eiRVPaDVc-37ggQ I will continue to update this comment with more mock ups as i go, as I haven't covered all possible changes just yet. Please share any thoughts or possible changes

GiteaMirror commented 2025-11-11 14:21:28 -06:00

Author

Owner

Copy Link

@tjbck commented on GitHub (Jun 8, 2024):

Closing in favour of https://github.com/open-webui/open-webui/issues/2924

@tjbck commented on GitHub (Jun 8, 2024): Closing in favour of https://github.com/open-webui/open-webui/issues/2924

GiteaMirror referenced this issue 2025-11-11 17:18:56 -06:00

[PR #548] [MERGED] feat: custom interface support #7166

GiteaMirror referenced this issue 2026-04-19 18:49:00 -05:00

[GH-ISSUE #440] feat: option to disable suggested prompts #12058

GiteaMirror referenced this issue 2026-04-20 02:55:34 -05:00

[PR #548] [MERGED] feat: custom interface support #20370

GiteaMirror referenced this issue 2026-04-25 02:17:44 -05:00

[GH-ISSUE #440] feat: option to disable suggested prompts #27586

GiteaMirror referenced this issue 2026-04-25 10:05:08 -05:00

[PR #548] [MERGED] feat: custom interface support #36000

GiteaMirror referenced this issue 2026-04-29 17:31:31 -05:00

[PR #548] [MERGED] feat: custom interface support #43418

GiteaMirror referenced this issue 2026-05-05 10:59:04 -05:00

[GH-ISSUE #440] feat: option to disable suggested prompts #50723

GiteaMirror referenced this issue 2026-05-06 01:08:57 -05:00

[PR #548] [MERGED] feat: custom interface support #59226

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 core enhancement

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#440