[GH-ISSUE #19752] issue: minor UI Bug: knowledge sharing #18984

New Issue

GiteaMirror · 2026-04-20T01:16:33-05:00

GiteaMirror commented

2026-04-20 01:16:33 -05:00

Originally created by @mahenning on GitHub (Dec 4, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/19752

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

0.6.41

Ollama Version (if applicable)

No response

Operating System

Ubuntu 22.04

Browser (if applicable)

No response

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

If admins enable knowledge sharing but disable knowledge public sharing, the user should only be able to see the option to share their knowledge base to groups, or have only the "Private" option in the Visibility dropdown menu.

Actual Behavior

Users see the Visibility dropdown menu with "Private / Public" options when knowledge sharing is enabled, but knowledge public sharing is disabled. They can select "Public" and click save, and then get a message with "Knowledge updated successfully!".
The knowledge is not made public and after re-loading the page, Access control shows private again. So that works. The only thing is that users may think sharing is possible, because the UI shows no restriction / error.

Steps to Reproduce

As admin enable knowledge sharing but disable knowledge public sharing
Let user A create a knowledge and try setting it to "Public". See a success message in the UI.
Reload the page to see that access is not actual public
(Check with user B and # in chat to see that the knowledge of user A is still not public)

Logs & Screenshots

Additional Information

No response

Originally created by @mahenning on GitHub (Dec 4, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/19752 ### 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 0.6.41 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 22.04 ### Browser (if applicable) _No response_ ### 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 If admins enable `knowledge sharing` but disable `knowledge public sharing`, the user should only be able to see the option to share their knowledge base to groups, or have only the "Private" option in the `Visibility` dropdown menu. ### Actual Behavior Users see the Visibility dropdown menu with "Private / Public" options when `knowledge sharing` is enabled, but `knowledge public sharing` is disabled. They can select "Public" and click save, and then get a message with "Knowledge updated successfully!". The knowledge is not made public and after re-loading the page, Access control shows private again. So that works. The only thing is that users may think sharing is possible, because the UI shows no restriction / error. ### Steps to Reproduce 1. As admin enable `knowledge sharing` but disable `knowledge public sharing` 2. Let user A create a knowledge and try setting it to "Public". See a success message in the UI. 3. Reload the page to see that access is not actual public 4. (Check with user B and # in chat to see that the knowledge of user A is still not public) ### Logs & Screenshots <img width="905" height="570" alt="Image" src="https://github.com/user-attachments/assets/6c0ba9cb-fdfc-4a1e-b71d-51b4b63b7404" /> <img width="913" height="670" alt="Image" src="https://github.com/user-attachments/assets/471b8c0a-9506-49b0-b87e-1383b9019099" /> ### Additional Information _No response_

GiteaMirror added the confirmed issue bug labels 2026-04-20 01:16:33 -05:00

GiteaMirror closed this issue

2026-04-20 01:16:34 -05:00

GiteaMirror commented

2026-04-20 01:16:35 -05:00

@owui-terminator[bot] commented on GitHub (Dec 4, 2025):

🔍 Similar Issues Found

I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:

#19701 issue: knowledge can not multiple upload file
by willy808 • Dec 03, 2025 • bug
#19563 issue:
by naruto7g • Nov 28, 2025 • bug
#19211 issue:
by Byrnes9 • Nov 16, 2025 • bug
#19438 issue: Icon loading regression
by JoelShepard • Nov 24, 2025 • bug
#15638 issue:
by PaulX1029 • Jul 11, 2025 • bug

Show 5 more related issues

#14440 issue:
by ehsan8203 • May 28, 2025 • bug
#17390 issue:
by abxis • Sep 12, 2025 • bug
#17392 issue:
by abxis • Sep 12, 2025 • bug
#17389 issue:
by abxis • Sep 12, 2025 • bug
#17393 issue:
by abxis • Sep 12, 2025 • bug

💡 Tips:

If this is a duplicate, please consider closing this issue and adding any additional details to the existing one
If you found a solution in any of these issues, please share it here to help others

This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.

@owui-terminator[bot] commented on GitHub (Dec 4, 2025): 🔍 **Similar Issues Found** I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions: 1. [#19701](https://github.com/open-webui/open-webui/issues/19701) **issue: knowledge can not multiple upload file** *by willy808 • Dec 03, 2025 • `bug`* 2. [#19563](https://github.com/open-webui/open-webui/issues/19563) **issue:** *by naruto7g • Nov 28, 2025 • `bug`* 3. [#19211](https://github.com/open-webui/open-webui/issues/19211) **issue:** *by Byrnes9 • Nov 16, 2025 • `bug`* 4. [#19438](https://github.com/open-webui/open-webui/issues/19438) **issue: Icon loading regression** *by JoelShepard • Nov 24, 2025 • `bug`* 5. [#15638](https://github.com/open-webui/open-webui/issues/15638) **issue:** *by PaulX1029 • Jul 11, 2025 • `bug`* <details> <summary>Show 5 more related issues</summary> 6. [#14440](https://github.com/open-webui/open-webui/issues/14440) **issue:** *by ehsan8203 • May 28, 2025 • `bug`* 7. [#17390](https://github.com/open-webui/open-webui/issues/17390) **issue:** *by abxis • Sep 12, 2025 • `bug`* 8. [#17392](https://github.com/open-webui/open-webui/issues/17392) **issue:** *by abxis • Sep 12, 2025 • `bug`* 9. [#17389](https://github.com/open-webui/open-webui/issues/17389) **issue:** *by abxis • Sep 12, 2025 • `bug`* 10. [#17393](https://github.com/open-webui/open-webui/issues/17393) **issue:** *by abxis • Sep 12, 2025 • `bug`* </details> --- 💡 **Tips:** - If this is a duplicate, please consider closing this issue and adding any additional details to the existing one - If you found a solution in any of these issues, please share it here to help others *This comment was generated automatically by a bot.* Please react with a 👍 if this comment was helpful, or a 👎 if it was not.

GiteaMirror commented

2026-04-20 01:16:35 -05:00

@Classic298 commented on GitHub (Dec 4, 2025):

aha interesting. I will try to reproduce. This might indeed be a visual bug

@Classic298 commented on GitHub (Dec 4, 2025): aha interesting. I will try to reproduce. This might indeed be a visual bug

GiteaMirror commented

2026-04-20 01:16:35 -05:00

@rgaricano commented on GitHub (Dec 4, 2025):

(I∀I)
A possible implementation to fix the UI inconsistency (Public visibility option is shown to unauthorized users):

Update AccessControl.svelte to properly validate permissions

Add explicit validation to ensure the Public option is only shown when truly permitted:

<!-- In AccessControl.svelte, around line 129 -->
{#if share && sharePublic && hasPublicSharingPermission}
    <option class="text-gray-700" value="public" selected>{$i18n.t('Public')}</option>
{/if}

Add this validation function in the script section:

// Add to AccessControl.svelte script section
$: hasPublicSharingPermission = sharePublic && (
    $user?.role === 'admin' || 
    $user?.permissions?.sharing?.public_knowledge === true
);

Add client-side validation before allowing Public selection. To provide immediate feedback, add validation in the on:change handler:

<!-- In AccessControl.svelte, modify the on:change handler around line 110 -->
on:change={(e) => {
    if (e.target.value === 'public') {
        // Double-check permission before allowing public
        if (!($user?.role === 'admin' || $user?.permissions?.sharing?.public_knowledge)) {
            toast.error($i18n.t('You do not have permission to make items public'));
            e.target.value = 'private';
            return;
        }
        accessControl = null;
    } else {
        accessControl = {
            read: {
                group_ids: [],
                user_ids: []
            },
            write: {
                group_ids: [],
                user_ids: []
            }
        };
    }
    onChange(accessControl);
}}

Optional: Add visual indicator for permission level showing why Public isn't available:

<!-- In AccessControl.svelte, around the select element -->
{#if share && !sharePublic}
    <Tooltip content={$i18n.t('Public sharing requires admin or public_knowledge permission')}>
        <div class="opacity-50 cursor-not-allowed">
            <!-- Your select element here -->
        </div>
    </Tooltip>
{:else}
    <!-- Normal select element -->
{/if}

@rgaricano commented on GitHub (Dec 4, 2025): (I∀I) A possible implementation to fix the UI inconsistency (Public visibility option is shown to unauthorized users): - Update AccessControl.svelte to properly validate permissions Add explicit validation to ensure the Public option is only shown when truly permitted: ```svelte  {#if share && sharePublic && hasPublicSharingPermission} <option class="text-gray-700" value="public" selected>{$i18n.t('Public')}</option> {/if} ``` - Add this validation function in the script section: ```svelte // Add to AccessControl.svelte script section $: hasPublicSharingPermission = sharePublic && ( $user?.role === 'admin' || $user?.permissions?.sharing?.public_knowledge === true ); ``` - Add client-side validation before allowing Public selection. To provide immediate feedback, add validation in the `on:change` handler: ```svelte  on:change={(e) => { if (e.target.value === 'public') { // Double-check permission before allowing public if (!($user?.role === 'admin' || $user?.permissions?.sharing?.public_knowledge)) { toast.error($i18n.t('You do not have permission to make items public')); e.target.value = 'private'; return; } accessControl = null; } else { accessControl = { read: { group_ids: [], user_ids: [] }, write: { group_ids: [], user_ids: [] } }; } onChange(accessControl); }} ``` - Optional: Add visual indicator for permission level showing why Public isn't available: ```svelte  {#if share && !sharePublic} <Tooltip content={$i18n.t('Public sharing requires admin or public_knowledge permission')}> <div class="opacity-50 cursor-not-allowed">  </div> </Tooltip> {:else}  {/if} ```

GiteaMirror commented

2026-04-20 01:16:35 -05:00

@silentoplayz commented on GitHub (Dec 4, 2025):

I can confirm that I am able to reproduce this issue with the provided reproduction steps on the latest dev commit.

@silentoplayz commented on GitHub (Dec 4, 2025): I can confirm that I am able to reproduce this issue with the provided reproduction steps on the latest dev commit.

GiteaMirror commented

2026-04-20 01:16:35 -05:00

@silentoplayz commented on GitHub (Dec 15, 2025):

I've just retested this issue and it appears that it may have been silently solved in the current dev branch. @mahenning, @rgaricano Could either of you report back on whether it is addressed for you or not?

@silentoplayz commented on GitHub (Dec 15, 2025): I've just retested this issue and it appears that it may have been silently solved in the current `dev` branch. @mahenning, @rgaricano Could either of you report back on whether it is addressed for you or not?

GiteaMirror commented

2026-04-20 01:16:36 -05:00

@mahenning commented on GitHub (Dec 16, 2025):

I can confirm that on dev, I'm not able to set a knowledge to public when public sharing is disabled. Nice work!

@mahenning commented on GitHub (Dec 16, 2025): I can confirm that on `dev`, I'm not able to set a knowledge to public when public sharing is disabled. Nice work!

GiteaMirror referenced this issue

2026-04-20 05:43:42 -05:00

[PR #18984] [CLOSED] Fix: Restore Native Tools function calls #25047

GiteaMirror referenced this issue

2026-04-25 08:11:25 -05:00

[GH-ISSUE #18981] issue: 0.6.35 error using tools through mcpo #34266

GiteaMirror referenced this issue

2026-04-25 13:07:41 -05:00

[PR #18984] [CLOSED] Fix: Restore Native Tools function calls #40677

GiteaMirror referenced this issue

2026-04-29 23:36:27 -05:00

[PR #18984] [CLOSED] Fix: Restore Native Tools function calls #48095