[UserCap BE]: UserCap availability
In &4315, we introduced a User Cap
setting for self-managed admins to prevent accidental user overages, now we are doing the same for SaaS group owners to prevent accidental overages.
This work will be broken down into the following backend steps:
- Add user cap setting
- Adding/inviting members
- Notifications
- Member management
- Auto approval
- Approval Modal
- Group access modifications
- Group sharing
-
UserCap availability :
👈🏽 we are here
As per the discussion here, the UserCap feature should be not be available when:
- the root ancestor group is sharing itself or any sub-groups with a group outside of the hierarchy
If this is the case, then there should be a notice displayed to explain that the UserCap feature is not available because they are sharing outside of their namespace.
Relevant links
- Epic: &5803 (closed)
Implementation plan
-
Add validation for User Cap enablement to check if any group in hierarchy is shared -
Add validation to ensure User Cap feature can be used (on Gitlab.com and feature flag enabled) -
Provide front-end with sharing status for form field disabling -
(Optional - could be split to FE issue) - disable form field and display notice based on previous point
Additional notes
Although I've not fully investigated what's involved in delivering this change, some things I'm aware of are:
I believe we create group_group_link
table entries when a group is shared with another, so we can use that to determine if any of the groups in the hierarchy have been shared. There may already be convenience methods in place for this, I haven't checked yet.
There will likely be a small intricacy here, in that it's possible to share a sub-group with another sub-group within the same hierarchy, so we'd need to check both group_group_links.shared_with_group_id
and group_group_links.shared_group_id
values accordingly to ensure we're ruling out internal group sharing.