Prevent :remove_{group,project} when ancestor is scheduled for deletion
What does this MR do and why?
This change adds more granular control over deletion permissions for groups and projects in a hierarchical structure.
Previously, the system would prevent certain actions if either the item itself OR any of its parent items were scheduled for deletion. Now, the code can distinguish between these two scenarios - it can check if just the item itself is scheduled for deletion versus if a parent/ancestor is scheduled for deletion.
The main improvements include:
- Added an optional parameter to exclude the current item when checking for deletion schedules in the hierarchy
- Updated permission rules so that users cannot remove groups or projects when a parent is scheduled for deletion (even if the item itself isn't)
- Modified the deletion checking logic for groups/projects to only look at ancestors, not the group/project itself
- Added comprehensive tests to verify these new permission rules work correctly
This prevents users from accidentally removing items when their parent containers are already being deleted, while still allowing normal operations when only the item itself is scheduled for deletion.
References
- Related to Marking a group as 'pending deletion' should di... (#549074 - closed) • Rémy Coutable • 18.4
How to set up and validate locally
- Mark a group for deletion
- Check that a child group or project cannot be marked for deletion itself as long as their parent is marked for deletion
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.