Trash and restore#

Deleting a ticket, a comment, a wiki page or an attachment does not destroy it immediately. It goes to the workspace trash, where it can be put back for 30 days. After that a sweep destroys it permanently, including the stored bytes of any attachment.

This replaces the older behaviour, where a delete was immediate and final from the user's point of view.

What the trash holds#

The trash is per workspace and lists only what is still recoverable — anything already past its 30 days is left out, even if the sweep has not run yet. Offering a restore button for something about to be destroyed is worse than not offering one.

Using it#

There is no interface for this yet; it is API-only.

# What can still be put back
curl https://api.laver.app/workspaces/$WORKSPACE/trash \
  -H "Authorization: Bearer $TOKEN"

# Put one back
curl -X POST https://api.laver.app/workspaces/$WORKSPACE/trash/ticket/$UUID/restore \
  -H "Authorization: Bearer $TOKEN"

# Destroy one now, without waiting out the 30 days
curl -X DELETE https://api.laver.app/workspaces/$WORKSPACE/trash/ticket/$UUID \
  -H "Authorization: Bearer $TOKEN"

Who can do what. Anyone who can read the workspace can see the trash. Restoring and destroying are writes, so a viewer cannot do either, and neither can anyone in a workspace that is read-only because of billing.

After 30 days#

An hourly sweep destroys anything past the window. For an attachment this also deletes the file from object storage — until this existed, the bytes of a deleted attachment stayed in the bucket indefinitely.

Destroying something from the trash yourself is immediate and is not recoverable. That is the only genuinely permanent delete in the product.

What this does not cover#

• A deleted board or workspace. Those are separate, older paths — see Export and deletion.
• Ticket history. Restoring a ticket brings back the ticket, its comments and its attachments; it does not reconstruct anything that was edited rather than deleted.