Skip to content

Let project and sandbox owners cancel a scheduled deletion themselves #4673

@elias-ba

Description

@elias-ba

Context

We soft-delete a few things in OpenFn and the recovery path isn't quite consistent across them:

  • Credentials. The owner sees a Cancel deletion link inline in their credentials list and can restore it themselves.
  • Projects. Only superusers can cancel a scheduled deletion, from /settings/projects. Project owners and admins have to escalate.
  • Sandboxes (after sandboxes: soft delete on merge #4649). Same as projects: hidden from the user-facing list during the grace period, only restorable by a superuser via the same admin page.

The asymmetry is a bit awkward. If a project owner had the permission to schedule the deletion in the first place, it feels reasonable that they should be able to cancel it within the grace period without having to ping a superuser.

It would also help with the original motivation of #4649 ("someone deleted by mistake and is freaking out"), since that scenario currently still requires an escalation.

Proposal

Bring projects and sandboxes in line with the credentials model: anyone who has the permission to delete should also be able to cancel a scheduled deletion during the grace period.

For projects, that means the owner role (matching :delete_project).

For sandboxes, that means the same actors as :delete_sandbox (owner/admin on the sandbox or on any ancestor), which is what Sandboxes.cancel_scheduled_sandbox_deletion/2 already gates on. It just isn't surfaced in the UI yet.

Things to consider

  • Where does the cancel UI live? For sandboxes specifically, sandboxes: soft delete on merge #4649 hides scheduled-deletion sandboxes from the parent's sandbox tab. We'd either need to bring them back with a "scheduled for deletion" badge and a Cancel button, or add a separate "Recently deleted" section on that page. Worth a small design conversation.
  • Projects are trickier. Once a project is scheduled for deletion the user is effectively logged out of it (subsequent logins are blocked). We'd need somewhere outside the project itself for the owner to see and cancel it (maybe the Projects overview page, or a one-off recovery link in the deletion email).
  • Backend is mostly already there. Lightning.Projects.cancel_scheduled_deletion/1 and Sandboxes.cancel_scheduled_sandbox_deletion/2 (added in sandboxes: soft delete on merge #4649) both exist. The work is mostly UI plus tightening the permission gate on the project version (it currently has none, so anyone who knows the project ID could call it).
  • Risk: accidental cancel. Probably low. A confirm dialog would be enough. Worth thinking about whether we want an audit log entry too, since "delete then cancel" can happen near a real concern.

Not super urgent (the support escalation path works today), but it would close the loop nicely on the soft-delete story and remove a small but recurring source of friction.

Metadata

Metadata

Assignees

No one assigned

    Labels

    sandboxes and syncTracking efforts to support sandbox and prod modesux/ui improvementImprovements to the look, feel and usability of the system

    Type

    No type

    Projects

    Status

    Product Backlog

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions