I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.
Verify Feature Scope
I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.
Problem Description
Right now we can add users to groups, this is great, but its not scalable. We have 15 access groups and growing, adding an employee to each one and remembering which ones this tyep of employee shoudl have is a management hassle. If a new employee comes on board we can only assign them to one group that has access to one thing instead of one group with access to the thigns a default employee should be able to answer.
You can make a group and apply it to all the things and use that group but then you still need other groups for granular controls, its double the work and much harder to audit what access a group has access to.
We need to be able to add groups to groups, this is the proper authentication model for businesses.
Desired Solution you'd like
Example:
Group:
Employees: this group is placed inside the following groups "cheap_ai, sanitized_company_AI MCP"
leads: this group is placed inside the following groups "cheap_ai, mid-tier-ai, sanitized_company_data, Internet"
Officers: this group is placed inside the following groups "cheap_ai, mid-tier-ai, premium ai, sanitized_company_data mcp, restricted_company_ai mcp, Internet"
We already have about 15 acess groups, no one wants to go add a new user to all the groups especially when all users fall into 1 of 3 categories for access. Group in a group is best practice, clean and aligns to how businesses do business. Add a user to one group, add exceptions as needed, auto start them with a full set of rights for an employee instead of a single group with access to a single resource.
Alternatives Considered
You can make a group and apply it to all the things and use that group but then you still need other groups for granular controls, its double the work and much harder to audit what access a group has access to.
Additional Context
If you are interested in this feature, I am good with contributing, I can add it and push a pr.
Originally created by @EncryptShawn on GitHub (Apr 30, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24266
### Check Existing Issues
- [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request.
### Verify Feature Scope
- [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.
### Problem Description
Right now we can add users to groups, this is great, but its not scalable. We have 15 access groups and growing, adding an employee to each one and remembering which ones this tyep of employee shoudl have is a management hassle. If a new employee comes on board we can only assign them to one group that has access to one thing instead of one group with access to the thigns a default employee should be able to answer.
You can make a group and apply it to all the things and use that group but then you still need other groups for granular controls, its double the work and much harder to audit what access a group has access to.
We need to be able to add groups to groups, this is the proper authentication model for businesses.
### Desired Solution you'd like
Example:
Group:
Employees: this group is placed inside the following groups "cheap_ai, sanitized_company_AI MCP"
leads: this group is placed inside the following groups "cheap_ai, mid-tier-ai, sanitized_company_data, Internet"
Officers: this group is placed inside the following groups "cheap_ai, mid-tier-ai, premium ai, sanitized_company_data mcp, restricted_company_ai mcp, Internet"
We already have about 15 acess groups, no one wants to go add a new user to all the groups especially when all users fall into 1 of 3 categories for access. Group in a group is best practice, clean and aligns to how businesses do business. Add a user to one group, add exceptions as needed, auto start them with a full set of rights for an employee instead of a single group with access to a single resource.
### Alternatives Considered
You can make a group and apply it to all the things and use that group but then you still need other groups for granular controls, its double the work and much harder to audit what access a group has access to.
### Additional Context
If you are interested in this feature, I am good with contributing, I can add it and push a pr.
You want.. to add a group to a group in the sense that
If user gets added to group A1 (which is... "inside" Group A) that the user then gets auto-assigned to both group A1 and group A?
<!-- gh-comment-id:4354063805 -->
@Classic298 commented on GitHub (Apr 30, 2026):
Wait i am not quite sure I understand
You want.. to add a group to a group in the sense that
If user gets added to group A1 (which is... "inside" Group A) that the user then gets auto-assigned to both group A1 and group A?
Basically enterprise software most of the time allow nesting for groups. They dont get douplicated, the point is the oposite. Every RIGHTCHECK every permission "resolves" the permited groups and their membergroups, their membergroups and so on access. If a group has a group in it they get recursively resolved.
This is how big enterprises structure all their permissions as the abstraction allows for less work becasue it basically allows administrators to set rights in a way in the principle of "don't repeat yourselft". The whole Microsoft Active Directory in most organizations is basically a Mountain of nested permissions - Microsoft even has complex best practice strategies for nesting like AGDLP - where you nest groups to make things easier (and more performant for huge organizations) in the long run. These nested abstractions are the fundation for using a shipload of komplex permissions. As bigger and more complex the permissions get and as more users you have with various defferrenting rights, the more important becomes the strategy of nested groups.
In the most simple beginning, groups follow department logics. As departments are hirarchical in most organizations and maybe have sub departments the subdepartment groups is member of the correlating department.
Lets say
Group A members:
User 1
User 2
User 3
User 4
Group B members:
User 2
User 3
User 5
User 6
User 7
Group C members:
User 4
User 8
User 9
Group B
Group D members:
Group A
Group B
Group C
(In this case it is important that resolving the permissions don't break if a users is permitted by various rights)
Group E members:
User 4
Group A
Group B
(In this case it is important that resolving the permissions don't break if a users is permitted by various rights)
Group F members:
User 10
Group E
So now Imagine you have to give a specific Tool or Model unique for each group with specific configuration - the users in that groups are your everyday office user that you definitely don't want to fiddle arround with the depths of OWUI - they are just everyday users. Creating Groups A to F without nested groups would be VERY tiresome for the admin.
Also what should be taken care of is: If a ressource like a note is permitted readonly for Group D and write to Group B, then the users from B should have write rights, it should not be overwritten because being in Group D gives them readonly.
Edit:
I guess and estimate this would require A LOT of rework for all the permission system and would make things very much complex. This probably should not be underestimated! Very often Software has bugs especially because nesting of groups fail.
So this is probably not a tiny little thing to make an easy PR for.
<!-- gh-comment-id:4355590318 -->
@TomTheWise commented on GitHub (Apr 30, 2026):
Basically enterprise software most of the time allow nesting for groups. They dont get douplicated, the point is the oposite. Every RIGHTCHECK every permission "resolves" the permited groups and their membergroups, their membergroups and so on access. If a group has a group in it they get recursively resolved.
This is how big enterprises structure all their permissions as the abstraction allows for less work becasue it basically allows administrators to set rights in a way in the principle of "don't repeat yourselft". The whole Microsoft Active Directory in most organizations is basically a Mountain of nested permissions - Microsoft even has complex best practice strategies for nesting like AGDLP - where you nest groups to make things easier (and more performant for huge organizations) in the long run. These nested abstractions are the fundation for using a shipload of komplex permissions. As bigger and more complex the permissions get and as more users you have with various defferrenting rights, the more important becomes the strategy of nested groups.
In the most simple beginning, groups follow department logics. As departments are hirarchical in most organizations and maybe have sub departments the subdepartment groups is member of the correlating department.
Lets say
Group A members:
- User 1
- User 2
- User 3
- User 4
Group B members:
- User 2
- User 3
- User 5
- User 6
- User 7
Group C members:
- User 4
- User 8
- User 9
- Group B
Group D members:
- Group A
- Group B
- Group C
(In this case it is important that resolving the permissions don't break if a users is permitted by various rights)
Group E members:
- User 4
- Group A
- Group B
(In this case it is important that resolving the permissions don't break if a users is permitted by various rights)
Group F members:
- User 10
- Group E
So now Imagine you have to give a specific Tool or Model unique for each group with specific configuration - the users in that groups are your everyday office user that you definitely don't want to fiddle arround with the depths of OWUI - they are just everyday users. Creating Groups A to F without nested groups would be VERY tiresome for the admin.
Also what should be taken care of is: If a ressource like a note is permitted readonly for Group D and write to Group B, then the users from B should have write rights, it should not be overwritten because being in Group D gives them readonly.
Edit:
I guess and estimate this would require A LOT of rework for all the permission system and would make things very much complex. This probably should not be underestimated! Very often Software has bugs especially because nesting of groups fail.
So this is probably not a tiny little thing to make an easy PR for.
Thanks for the detailed writeup @TomTheWise — you're right that full AD-style runtime resolution of nested groups would essentially require reworking every permission check in the codebase. That's a massive undertaking and a huge bug surface.
A more realistic approach would be to add a parent field (as a JSON entry or column) to the group table. When a user gets added to a group, we walk the parent chain up to the root and materialize the memberships in all parent groups (aka add the user to all groups in that group chain). The user actually gets added to each group along the chain - or removed when removing the user.
This means the entire existing permission system stays untouched — every access check still just does a simple "is user in group" lookup. You still get the hierarchical organization benefit: add a user to "Employees" and they automatically land in all the right access groups.
The tradeoff is that if the hierarchy itself changes (e.g. you reparent a group), we'd need to re-sync memberships. But that's a much smaller problem to solve than rewriting the auth layer. That'd require one new api endpoint for resyncing all members of a group instead of rewriting all access checks across the codebase.
Would this cover your use case?
<!-- gh-comment-id:4355686405 -->
@Classic298 commented on GitHub (Apr 30, 2026):
Thanks for the detailed writeup @TomTheWise — you're right that full AD-style runtime resolution of nested groups would essentially require reworking every permission check in the codebase. That's a massive undertaking and a huge bug surface.
A more realistic approach would be to add a `parent` field (as a JSON entry or column) to the group table. When a user gets added to a group, we walk the parent chain up to the root and materialize the memberships in all parent groups (aka add the user to all groups in that group chain). The user actually gets added to each group along the chain - or removed when removing the user.
This means the entire existing permission system stays untouched — every access check still just does a simple "is user in group" lookup. You still get the hierarchical organization benefit: add a user to "Employees" and they automatically land in all the right access groups.
The tradeoff is that if the hierarchy itself changes (e.g. you reparent a group), we'd need to re-sync memberships. But that's a much smaller problem to solve than rewriting the auth layer. That'd require one new api endpoint for resyncing all members of a group instead of rewriting all access checks across the codebase.
Would this cover your use case?
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @EncryptShawn on GitHub (Apr 30, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24266
Check Existing Issues
Verify Feature Scope
Problem Description
Right now we can add users to groups, this is great, but its not scalable. We have 15 access groups and growing, adding an employee to each one and remembering which ones this tyep of employee shoudl have is a management hassle. If a new employee comes on board we can only assign them to one group that has access to one thing instead of one group with access to the thigns a default employee should be able to answer.
You can make a group and apply it to all the things and use that group but then you still need other groups for granular controls, its double the work and much harder to audit what access a group has access to.
We need to be able to add groups to groups, this is the proper authentication model for businesses.
Desired Solution you'd like
Example:
Group:
Employees: this group is placed inside the following groups "cheap_ai, sanitized_company_AI MCP"
leads: this group is placed inside the following groups "cheap_ai, mid-tier-ai, sanitized_company_data, Internet"
Officers: this group is placed inside the following groups "cheap_ai, mid-tier-ai, premium ai, sanitized_company_data mcp, restricted_company_ai mcp, Internet"
We already have about 15 acess groups, no one wants to go add a new user to all the groups especially when all users fall into 1 of 3 categories for access. Group in a group is best practice, clean and aligns to how businesses do business. Add a user to one group, add exceptions as needed, auto start them with a full set of rights for an employee instead of a single group with access to a single resource.
Alternatives Considered
You can make a group and apply it to all the things and use that group but then you still need other groups for granular controls, its double the work and much harder to audit what access a group has access to.
Additional Context
If you are interested in this feature, I am good with contributing, I can add it and push a pr.
@Classic298 commented on GitHub (Apr 30, 2026):
Wait i am not quite sure I understand
You want.. to add a group to a group in the sense that
If user gets added to group A1 (which is... "inside" Group A) that the user then gets auto-assigned to both group A1 and group A?
@TomTheWise commented on GitHub (Apr 30, 2026):
Basically enterprise software most of the time allow nesting for groups. They dont get douplicated, the point is the oposite. Every RIGHTCHECK every permission "resolves" the permited groups and their membergroups, their membergroups and so on access. If a group has a group in it they get recursively resolved.
This is how big enterprises structure all their permissions as the abstraction allows for less work becasue it basically allows administrators to set rights in a way in the principle of "don't repeat yourselft". The whole Microsoft Active Directory in most organizations is basically a Mountain of nested permissions - Microsoft even has complex best practice strategies for nesting like AGDLP - where you nest groups to make things easier (and more performant for huge organizations) in the long run. These nested abstractions are the fundation for using a shipload of komplex permissions. As bigger and more complex the permissions get and as more users you have with various defferrenting rights, the more important becomes the strategy of nested groups.
In the most simple beginning, groups follow department logics. As departments are hirarchical in most organizations and maybe have sub departments the subdepartment groups is member of the correlating department.
Lets say
Group A members:
Group B members:
Group C members:
Group D members:
(In this case it is important that resolving the permissions don't break if a users is permitted by various rights)
Group E members:
(In this case it is important that resolving the permissions don't break if a users is permitted by various rights)
Group F members:
So now Imagine you have to give a specific Tool or Model unique for each group with specific configuration - the users in that groups are your everyday office user that you definitely don't want to fiddle arround with the depths of OWUI - they are just everyday users. Creating Groups A to F without nested groups would be VERY tiresome for the admin.
Also what should be taken care of is: If a ressource like a note is permitted readonly for Group D and write to Group B, then the users from B should have write rights, it should not be overwritten because being in Group D gives them readonly.
Edit:
I guess and estimate this would require A LOT of rework for all the permission system and would make things very much complex. This probably should not be underestimated! Very often Software has bugs especially because nesting of groups fail.
So this is probably not a tiny little thing to make an easy PR for.
@Classic298 commented on GitHub (Apr 30, 2026):
Thanks for the detailed writeup @TomTheWise — you're right that full AD-style runtime resolution of nested groups would essentially require reworking every permission check in the codebase. That's a massive undertaking and a huge bug surface.
A more realistic approach would be to add a
parentfield (as a JSON entry or column) to the group table. When a user gets added to a group, we walk the parent chain up to the root and materialize the memberships in all parent groups (aka add the user to all groups in that group chain). The user actually gets added to each group along the chain - or removed when removing the user.This means the entire existing permission system stays untouched — every access check still just does a simple "is user in group" lookup. You still get the hierarchical organization benefit: add a user to "Employees" and they automatically land in all the right access groups.
The tradeoff is that if the hierarchy itself changes (e.g. you reparent a group), we'd need to re-sync memberships. But that's a much smaller problem to solve than rewriting the auth layer. That'd require one new api endpoint for resyncing all members of a group instead of rewriting all access checks across the codebase.
Would this cover your use case?