GitLab Next

Problem

One of the worst scenarios for an administrator is losing data without a path to recovery. We especially hear this with enterprises, who have large userbases (differing levels of familiarity with GitLab may lead to accidents).

To prevent this from happening with projects, we shipped #5615 (closed) - but this first iteration only helps self-managed instances. Ideally, we should have a flexible way of either preventing projects from being deleted without a recovery option or carving out a quick way to restore a deleted project that extends to GitLab.com.

Proposal

Require a soft deletion period for project removal.

• Attempting to remove a project marks it for deletion (and archives it, in the case of projects). It should no longer immediately remove the project.
• After X days have elapsed, the project or group is deleted.
  • An instance should be able to set this to 0 to essentially enable immediate removal, but this should not be default behavior. Default behavior should be something like 7 days.
• Attempting to delete something:
  • The "remove project" container for projects should reflect the soft deletion period.
  • A project pending deletion should be archived and marked for deletion. I should be able to tell that a project is marked for deletion in the UI and via an attribute associated with the project (obtainable via the Projects API).
  • Attempting to delete a project with the API should also result in the soft deletion period as described above.
• Recovering a project or group pending deletion:
  • Include a "restore" button in project/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.

Mockups

Marking a project for deletion

• Change the "remove project" container to note the new approach:

• We'll need to also change text in the confirmation modal.

Displaying a project pending delete

• As a short-term path forward, we're recommending that we use our "archived project" design approach. We can note a project as pending deletion on the overview page:

• We should also update the archived badge we use in project lists to denote that a project is pending removal on the profile page:

Unmarking a project for deletion

• Add a "restore project" container to project settings:

Follow ups

See #33257 (closed) for extending soft delete to groups.

Additional detail

• Existing behavior of archived projects gets us mostly there in terms of read-only behavior of a project.
• For name conflicts (attempting to create a project with the same name as a project marked for deletion): it's fine to throw an error - the workaround would be renaming one of the projects. Could be a bit annoying, but something we can iterate on if we get feedback that these collisions happen often.