Skip to content

Prevent deleting group/project when ancestor is marked for deletion at the service level

What does this MR do and why?

This change improves how the system handles deletion scheduling for groups and projects in a hierarchical structure. Previously, the system had complex logic to prevent deletion of items when their parent was scheduled for deletion but still allowed it in some edge cases.

The update simplifies this by adding a new method to easily check if any ancestor is scheduled for deletion, then consistently blocks all deletion attempts (both immediate and scheduled) when an ancestor is already marked for deletion. This prevents confusing situations where users could try to delete something that would be automatically deleted anyway when its parent gets deleted.

The change also removes some redundant code in the user interface and policy files, consolidating the deletion prevention logic into a single, clearer approach. The API endpoints now return success immediately when trying to delete something whose ancestor is already scheduled for deletion, rather than processing the request unnecessarily.

Overall, this makes the deletion behavior more predictable and user-friendly by preventing redundant deletion requests while maintaining the same security permissions.

References

Screenshots or screen recordings

No visible changes.

How to set up and validate locally

  1. Mark a group for deletion
  2. Check that a child group or project cannot be marked for deletion itself (from their settings page and via the API) as long as their parent is marked for deletion
  3. Force-delete the group and ensure that the deletion goes through. The group, and its child group/project should all be deleted

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.

Edited by Rémy Coutable

Merge request reports

Loading