Preventing accidental project deletion via optional soft delete
The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
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.
- An instance should be able to set this to
- 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.