Skip to content

Add -deletion_scheduled- suffix for groups and projects scheduled for deletion

Problem

Customers often want to follow a specific naming structure and free up a namespace when deleting a group or project. Because we are not consistently guaranteeing auto-renaming of groups and projects, they often end up permanently deleting items to free up paths. To prevent users from being forced to delete groups or projects before the scheduled deletion date, and thus allowing them to recover the item if needed, we should ensure both groups and projects are automatically renamed when moved to a pending deletion state.

Projects

When projects are queued for deletion, the project name gets suffixed with [Project Name]-deleted-[Project ID] and added to the Inactive tab in the list of projects. This presents a few UX issues:

  • Users are not aware of this change and may be confused when trying to recover and search for the project
  • The -deleted suffix is misleading since the project isn't actually deleted yet, but queued for deletion.

Groups

Groups are currently not automatically renamed upon deletion, but we would like to introduce the same behavior as for projects. If we adjust the suffix for projects, we should use the same one for groups.

  • Consider that all child items within a group (subgroups and projects) will also be moved to a pending deletion state when the group is deleted.

Proposal

  • Add context to why projects have deleted suffix when queued for deletion
  • Update "-deleted-" suffix to "-deletion_scheduled-"

Implementation

  • When a project is moved to pending deletion, update the path from [Project Path] to [Project Path]-deletion_scheduled-[Project ID]
  • When a group is moved to pending deletion, update the path from [Group Path] to [Group Path]-deletion_scheduled-[Group ID]
  • When a project is restored, update the path from [Project Path]-deletion_scheduled-[Project ID] to:
    • [Project Path], if that path is still available
    • [Project Path]-#{SecureRandom.alphanumeric(5)}, if [Project Path] has been taken by another project
  • When a group is restored, update the path from [Group Path]-deletion_scheduled-[Group ID] to:
    • [Group Path], if that path is still available
    • [Group Path]-#{SecureRandom.alphanumeric(5)}, if [Group Path] has been taken by another group
  • This should be consistent regardless of whether the user is deleting the project or group from the Admin Area, group overview page, list views (Your Work and Explore), or the group and project settings

This means we need a mechanism to check whether a path is still available upon restore.

Edited by Rémy Coutable