You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Context
We soft-delete a few things in OpenFn and the recovery path isn't quite consistent across them:
Cancel deletionlink inline in their credentials list and can restore it themselves./settings/projects. Project owners and admins have to escalate.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 whatSandboxes.cancel_scheduled_sandbox_deletion/2already gates on. It just isn't surfaced in the UI yet.Things to consider
Projectsoverview page, or a one-off recovery link in the deletion email).Lightning.Projects.cancel_scheduled_deletion/1andSandboxes.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).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.