issue: users who may not share with groups are still offered the group picker in workspace access dialogs

Before Submitting

• I searched open and closed issues and discussions for an existing report.
• I reproduced this bug on the latest release AND on the current dev branch, right before submitting this report. I did not just check an old version or rely on a check from days ago.
• I understand that maintainers want a well-written issue before any code pull request.
• This is not a security vulnerability.

Installation Method

Git Clone

Open WebUI Version

dev commit 3d2954871

Operating System

Linux

Browser

Firefox

Ollama Version

No response

Summary

A user whose permissions do not allow sharing with groups is still offered the group list in every workspace access dialog. Adding a group there reports success, and the grant is dropped on the way in, so reopening the dialog shows it was never saved. The folder share dialog is the one place that hides the list correctly.

Expected Behavior

The access dialog for a model, prompt, tool, skill, knowledge base, note or chat hides the group list for a user who may not share with groups, the way the folder share dialog already does.

Actual Behavior

The group list is shown and the group can be picked. A success message appears. Reopening the dialog shows the group is not there, with nothing said about why.

Steps to Reproduce

1. Admin Panel, then Users, then Groups: create a group and add a second user B to it. In the group's permissions turn on prompts access and prompts sharing, and turn off Allow Sharing With Groups. Save.
2. Admin Panel, then Users, then the default permissions: turn off Allow Sharing With Groups there too, because the check is a union of the user's groups and the defaults. Save.
3. As B, open Workspace, then Prompts, then any prompt, then the access button, then the plus button. The picker lists a Groups section with the group in it.
4. Pick the group and close the dialog. A saved message appears.
5. Reload the page and reopen the access dialog: the group is gone.
6. For comparison, as the same user open a folder's share dialog and press plus: no Groups section is shown there.

Logs, Screenshots, and Config

Nothing is written to the server log or the browser console. The request succeeds and the grant is filtered out before it is stored. The only non-default settings are the two permission switches in steps 1 and 2.

Additional Information

The access control component already takes a flag for whether groups may be offered, and the folder share dialog sets it from the user's permission. The modal wrapper that every workspace page uses neither declares that flag nor passes it down, so it keeps its default of true, and none of the workspace pages set it either, although they all set the matching flag for individual users. On the server the grant list is filtered against the same permission and group grants are dropped silently, which is why the dialog reports success.

Start with the access control component and the modal wrapper used by workspace access dialogs; compare their group-sharing flag with the folder share dialog. Check the model, prompt, tool, skill, knowledge base, note, and chat access entry points, then reproduce the permissions scenario and verify that disallowed users no longer see the Groups section.