Include inherited owners when calculating User#solo_owned_groups
What does this MR do and why?
Previously User#solo_owned_groups
did not calculate with inherited ownership. This could lead to situations where a member would incorrectly destroy a sub-group. This MR includes inheritance in the ownership calculation by counting owners in self and ancestor namespaces.
How to set up and validate locally
-
user1
creates a top-level group -
user2
addsuser2
to the top-level group -
user2
creates a sub-group within this top-level group. This makesuser2
the sole explicit owner of the group, howeveruser1
is an inherited owner from the top-level group. -
user1
or someone else deletesuser2
along with contributions.
Previously: Observe that the sub-group no longer exists.
After the fix:
Observe that the sub-group continues to exist, because user1
is an inherited owner from the top level group, so there is no need to delete this subgroup..
Query plan
Typical case
Time: 4.781 ms
- planning: 1.138 ms
- execution: 3.643 ms
- I/O read: 0.000 ms
- I/O write: 0.000 ms
Shared buffers:
- hits: 1678 (~13.10 MiB) from the buffer pool
- reads: 0 from the OS file cache, including disk I/O
- dirtied: 0
- writes: 0
Details and visualization: https://postgres.ai/console/gitlab/gitlab-production-tunnel-pg12/sessions/10246/commands/36377.
Worst case
Time: 28.288 ms
- planning: 1.396 ms
- execution: 26.892 ms
- I/O read: 26.261 ms
- I/O write: 0.000 ms
Shared buffers:
- hits: 12 (~96.00 KiB) from the buffer pool
- reads: 21 (~168.00 KiB) from the OS file cache, including disk I/O
- dirtied: 0
- writes: 0
Details and visualization: https://postgres.ai/console/gitlab/gitlab-production-tunnel-pg12/sessions/10246/commands/36378.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Closes #26120 (closed)