[GH-ISSUE #12392] feat: Allow some way of manual group assignments when using OAUTH_GROUP_MANAGEMENT #55246

Open
opened 2026-05-05 17:21:52 -05:00 by GiteaMirror · 8 comments
Owner

Originally created by @Ithanil on GitHub (Apr 3, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/12392

Check Existing Issues

  • I have searched the existing issues and discussions.

Problem Description

When using OAUTH_GROUP_MANAGEMENT , any manual assignment of users to groups will be overriden upon next login of that user. This makes it impossible to manage user groups without relying on oauth claims.

Originally, I have interpreted the behavior as a completely different issue: https://github.com/open-webui/open-webui/issues/12306 and I'm sorry for my stupidity.

Desired Solution you'd like

In the envs for oauth group management, there should be a whitelist of groups to be managed or a blacklist of groups not to be managed.

Alternatives Considered

No response

Additional Context

No response

Originally created by @Ithanil on GitHub (Apr 3, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/12392 ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description When using OAUTH_GROUP_MANAGEMENT , any manual assignment of users to groups will be overriden upon next login of that user. This makes it impossible to manage user groups without relying on oauth claims. Originally, I have interpreted the behavior as a completely different issue: https://github.com/open-webui/open-webui/issues/12306 and I'm sorry for my stupidity. ### Desired Solution you'd like In the envs for oauth group management, there should be a whitelist of groups to be managed or a blacklist of groups not to be managed. ### Alternatives Considered _No response_ ### Additional Context _No response_
Author
Owner

@tjbck commented on GitHub (Apr 3, 2025):

PR Welcome here!

<!-- gh-comment-id:2776417604 --> @tjbck commented on GitHub (Apr 3, 2025): PR Welcome here!
Author
Owner

@dotmobo commented on GitHub (Apr 16, 2025):

+1

I have to managed extra groups with extra permissions and models. It would be a nice feature.

<!-- gh-comment-id:2809299877 --> @dotmobo commented on GitHub (Apr 16, 2025): +1 I have to managed extra groups with extra permissions and models. It would be a nice feature.
Author
Owner

@dotmobo commented on GitHub (Apr 17, 2025):

Well, i made a little PR here with a blacklist env variables : https://github.com/open-webui/open-webui/pull/12957

<!-- gh-comment-id:2812330002 --> @dotmobo commented on GitHub (Apr 17, 2025): Well, i made a little PR here with a blacklist env variables : https://github.com/open-webui/open-webui/pull/12957
Author
Owner

@taylorwilsdon commented on GitHub (Apr 20, 2025):

Well, i made a little PR here with a blacklist env variables : #12957

I was just about to start something with a different approach but I actually think this might be the better way. If we expose the "don't sync" list as an input in the admin panel in the same way as the other oauth settings like this https://github.com/open-webui/open-webui/pull/12945 it would be a sensible way to manage local sync groups. Anything else is going to require a more complicated approach that creates a linkage between IDP mastery and specific groups, and this is basically just the inverse with less scaffolding which imo is a sensible approach. @dotmobo let me know if I can help with anything there!

<!-- gh-comment-id:2817201263 --> @taylorwilsdon commented on GitHub (Apr 20, 2025): > Well, i made a little PR here with a blacklist env variables : [#12957](https://github.com/open-webui/open-webui/pull/12957) I was just about to start something with a different approach but I actually think this might be the better way. If we expose the "don't sync" list as an input in the admin panel in the same way as the other oauth settings like this https://github.com/open-webui/open-webui/pull/12945 it would be a sensible way to manage local sync groups. Anything else is going to require a more complicated approach that creates a linkage between IDP mastery and specific groups, and this is basically just the inverse with less scaffolding which imo is a sensible approach. @dotmobo let me know if I can help with anything there!
Author
Owner

@dotmobo commented on GitHub (Apr 20, 2025):

Thanks for your comment! I'm still waiting for approval from a maintainer, but of course, after that, it could be a great idea to add the feature to the #12945 admin management. Basically, I used a blacklist approach to minimize the impact on the current source code and avoid breaking changes.

<!-- gh-comment-id:2817315707 --> @dotmobo commented on GitHub (Apr 20, 2025): Thanks for your comment! I'm still waiting for approval from a maintainer, but of course, after that, it could be a great idea to add the feature to the #12945 admin management. Basically, I used a blacklist approach to minimize the impact on the current source code and avoid breaking changes.
Author
Owner

@wggcch commented on GitHub (Sep 4, 2025):

i created an PR #17196 would this also help?

<!-- gh-comment-id:3252608799 --> @wggcch commented on GitHub (Sep 4, 2025): i created an PR #17196 would this also help?
Author
Owner

@wggcch commented on GitHub (Sep 4, 2025):

also there is a new code block for regex oauth sync block list mentioned here df66e21472

<!-- gh-comment-id:3252644718 --> @wggcch commented on GitHub (Sep 4, 2025): also there is a new code block for regex oauth sync block list mentioned here https://github.com/open-webui/open-webui/commit/df66e21472646648d008ebb22b0e8d5424d491df
Author
Owner

@rndmcnlly commented on GitHub (Nov 7, 2025):

I'm looking for this functionality also, but I don't think I could maintain an allow/block list over time as groups churn.

Instead, I'm imagining some kind of OAUTH_GROUP_PREFIX var (initially empty string) so that I can make sure all of the managed groups have names like oauth:staff@example.com.

Alternatively, a regex could work for identifying the auto-managed groups. I'd configure it to only manage groups containing @.

The big thing is that whether a group is managed automatically is an obvious function of the group's current name. (This lets you adjust whether a group is managed or not by renaming it.)

<!-- gh-comment-id:3503608733 --> @rndmcnlly commented on GitHub (Nov 7, 2025): I'm looking for this functionality also, but I don't think I could maintain an allow/block list over time as groups churn. Instead, I'm imagining some kind of `OAUTH_GROUP_PREFIX` var (initially empty string) so that I can make sure all of the managed groups have names like `oauth:staff@example.com`. Alternatively, a regex could work for identifying the auto-managed groups. I'd configure it to only manage groups containing `@`. The big thing is that whether a group is managed automatically is an obvious function of the group's *current* name. (This lets you adjust whether a group is managed or not by renaming it.)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#55246