mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-06 19:08:59 -05:00
[GH-ISSUE #12392] feat: Allow some way of manual group assignments when using OAUTH_GROUP_MANAGEMENT #16580
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Ithanil on GitHub (Apr 3, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/12392
Check Existing Issues
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
@tjbck commented on GitHub (Apr 3, 2025):
PR Welcome here!
@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.
@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
@taylorwilsdon commented on GitHub (Apr 20, 2025):
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!
@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.
@wggcch commented on GitHub (Sep 4, 2025):
i created an PR #17196 would this also help?
@wggcch commented on GitHub (Sep 4, 2025):
also there is a new code block for regex oauth sync block list mentioned here
df66e21472@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_PREFIXvar (initially empty string) so that I can make sure all of the managed groups have names likeoauth: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.)