Prevent accidental deletions via soft delete for groups

Overview

We should follow up on #32935 (closed) by expanding soft delete to include groups.

Proposal

Require a soft deletion period for group removal.

• Attempting to remove a group marks it for deletion. It should no longer immediately remove the group.
• After X days have elapsed, the project or group is deleted.
  • We should use the same soft delete configuration introduced in #32935 (closed).
• Attempting to delete something:
  • The "remove group" container for group should reflect the soft deletion period.
  • A project pending deletion should be marked for deletion on the group overview page (banner, similar to the archived project notice) and group list (with a pending delete badge).
  • Attempting to delete a group with the API should also result in the soft deletion period as described above.
• Recovering a group pending deletion:
  • Include a "restore" button in group settings that unarchives the project and removes the soft deletion state.
  • Should be able to restore/remove the soft deletion state via API.
• Soft deletion and restore should trigger an audit event.

changed milestone to %12.5

added backend devopsmanage groupauthentication and authorization [DEPRECATED] labels

mentioned in issue #32935 (closed)

added [deprecated] Accepting merge requests label

added workflowplanning breakdown label

added frontend label

added estimationneeded label

changed the description

added direction label

changed title from Preventing accidental group deletion to Prevent accidental deletions via soft delete for groups

marked this issue as related to #32935 (closed)

Noting down some ideas/questions/edge cases for implementing soft-delete for groups. (not exhaustive)

1. Right now, we don't have an archive feature for groups, like we have for projects.

2. I feel that we should split this issue into further issues, so like,

   2.1 Implement archive feature for groups, so that the groups can be put to a read-only mode, where we recursively apply archival to it's subgroups and projects as well.

   2.2 Implement soft-delete after implementing archive functionality.

3. Implementing archive first also gives us the advantage of figuring out the places we need to add scopes/validations to prevent showing an archived group in api/UI/search results. (similar behaviour to an archived project) without the whole feature not becoming so over-whelming as I think figuring this out alone is going to be quite a bit of work.

4. After implementing archive, implement soft-delete for groups.

5. When soft-deleting a group, move the group to archived state and mark it for deletion (same as we do for projects) and also recursively move it's projects and subgroups to archived state ( marking these for deletion might be problematic because then we'd need to also make sure that deleting_marked_projects_destroy_cron_worker does not pick up these projects for deletion)

6. We'd also need to make sure that a project or a subgroup under a group that is already marked for deletion does not allow the user to mark these individually for deletion again.

7. We need to take care of a case where a project, say Project P under a group, say A group is already marked for deletion or is archived. We further mark "A group" for soft-delete on a future date. But we later restore this A group back to active state. Restoring A group back to active would also involve recursively changing its projects and subgroups back to active state - so this would restore Project P back to active state, even though it was archived/marked for deletion separately.

Please feel free to add anything I might have missed. Thoughts @mksionek @jeremy? :)

@manojmj thanks for your very thorough input on this!! Actually I was talking to @jeremy and what he proposed is to JUST mark group for deletion and then deleting it after N days, without an archived state. We can add it later on. The most important thing is to prevent accidental group deletions and let users restore it. Do you think it is ok to have just soft-delete in place and add an archive state in the next iteration?

Oh, thanks @mksionek, that makes real sense as an MVC!

So,

1. User marks the group for soft-delete.
2. There will be no changes to the group, or it's children after marking it for soft-delete (projects inside this group can be pushed to, new sub-groups can be created, new projects can be created, the group will keep appearing in search results - basically it continues acting like a normal group)
3. The only indication that the user gets about pending deletion is the the notice we will have up on the group page (should we extend the notice to be visible in it's subgroups and its projects as well?)
4. As per the application setting for adjourned delete, delete the group and its contents recursively on that specific date.
5. Allow the user to restore the group if they wish to, before it is permanently deleted.

Is this correct? :)

I believe so, I think we need @jeremy confirmation.

Thanks a lot for spelling out the MVC.

User marks the group for soft-delete.

Yes, from the group settings page where existing "delete" option is. This also applies to the API.

There will be no changes to the group, or it's children after marking it for soft-delete (projects inside this group can be pushed to, new sub-groups can be created, new projects can be created, the group will keep appearing in search results - basically it continues acting like a normal group)

Yes

The only indication that the user gets about pending deletion is the the notice we will have up on the group page (should we extend the notice to be visible in it's subgroups and its projects as well?)

The only thing I'm curious about is whether or not we're informing the user enough:

• I think it makes sense to add a pending deletion notice to the subgroups and projects. We can use a similar pattern that we are using in projects by putting a message on the overview page.
• Would it make sense to display a warning on the command line if we push or pull to a project that's pending deletion? We can consider this in a separate issue if it's significantly more effort, but I think that a developer who rarely signs into the GitLab UI should probably be informed that the project/group is pending deletion.

As per the application setting for adjourned delete, delete the group and its contents recursively on that specific date.

Yes

Allow the user to restore the group if they wish to, before it is permanently deleted.

Yes

@manojmj @mksionek, does that make sense to you?

yes, it does, but I agree that display a warning on the command line if we push or pull to a project that's pending deletion should have a separate issue...

Thanks @jeremy for pitching in. Agree with @mksionek on the above, the command line notice could be a different issue :) Everything else looks ok, I will start work on this once the project soft-deletion is done :)

@jeremy @mksionek Does a separate issue exist for the API handling of pending deletion projects/groups that you mentioned above?

See this GitHub issue for more info.

I don't know if there is a separate issue regarding this part:

display a warning on the command line if we push or pull to a project that's pending deletion should have a separate issue...

mentioned in merge request !18542 (closed)

assigned to @jeremy

removed [deprecated] Accepting merge requests label

changed weight to 5

added estimationcompleted label and removed estimationneeded label