Restore from trash

Problem Context

• Objects are removed from primary views but intentionally retained for a recovery period.
• Users may realize the deletion was wrong after navigating away, changing devices, or returning days later.
• Deleted objects may have parent folders, collaborators, permissions, versions, dependencies, or references that affect restore.
• Retention periods, admin purges, legal holds, storage quotas, or plan limits determine whether recovery is still possible.

Selection Rules

• Choose restore from trash when the product supports soft deletion and a recoverable deleted-items location.
• Use undo when recovery must happen immediately after a recent low-risk action and no durable deleted-items surface is needed.
• Use destructive action confirmation before permanent delete, empty trash, purge, or any deletion that bypasses recovery.
• Use draft state when users are recovering unpublished changes rather than deleted objects.
• Show original location, deletion time, deleted-by actor, object type, owner, and retention status before restore.
• Offer restore to original location only when that location still exists and the user has permission to restore there.
• Offer choose-location recovery when the parent object is gone, access changed, or a name conflict exists.
• For bulk restore, summarize item count, unavailable locations, conflicts, permission changes, and skipped items before applying the action.
• Avoid using trash as the only safety mechanism for high-risk permanent loss; users still need prevention, warnings, or confirmation when deletion has severe consequences.
• Make expired, purged, admin-only, and legal-hold states explicit instead of showing missing or disabled rows without explanation.

Required States

• Normal active-object state before deletion.
• Deleted-but-recoverable state in Trash or Recycle Bin.
• Trash list state with object metadata and restore actions.
• Restore preview state showing original location and affected permissions or dependencies.
• Restored state with a link to the restored object or location.
• Original-location unavailable state requiring a new destination or administrator help.
• Name conflict state when the original location already contains a replacement object.
• Retention-expiring state with a visible recovery deadline.
• Expired or purged state where recovery is no longer possible.
• Permanent delete or empty-trash confirmation state.

Interaction Contract

• Deleting an object removes it from normal views and records enough metadata for later recovery.
• Trash exposes recoverable deleted objects with identity, location, deletion, actor, and retention context.
• Restore returns the object to the original location when valid, or asks the user to choose a location when the original target is unavailable.
• The interface reports restored, skipped, conflicted, expired, purged, and permission-denied outcomes separately.
• Permanent delete and empty-trash actions require deliberate review and cannot be confused with Restore.
• Bulk selection preserves per-item status so users know which deleted objects can be restored safely.
• Restored objects become discoverable through a stable link, parent location, search result, or recent activity state.

Implementation Checklist

• Store deleted object ID, display name, object type, original parent, deleted-at timestamp, deleted-by actor, owner, permissions, version metadata, retention deadline, and purge status.
• Create a deleted-items view with filtering by type, owner, folder, deletion date, and restore availability.
• Validate the original location, permissions, name conflicts, quotas, locks, legal holds, and dependency references before restore.
• Provide restore-to-original and choose-new-location flows when the original parent cannot accept the object.
• Separate Restore, Delete forever, Empty trash, and Admin restore with distinct labels, placement, and confirmation requirements.
• Announce restore outcomes and failed-item details in a status region and preserve selection state for unresolved items.
• Test single restore, bulk restore, expired retention, parent deletion, name conflict, shared permissions, admin-only recovery, mobile access, keyboard access, and screen reader output.

Common Generated-UI Mistakes

• Showing deleted objects without enough metadata to identify the right item.
• Restoring to a hidden or invalid location without telling the user.
• Placing permanent delete beside Restore without visual separation or final-loss confirmation.
• Treating trash as a substitute for confirmation when deletion is severe or externally visible.
• Hiding retention deadlines, plan limits, or administrator-only recovery boundaries.
• Making bulk restore all-or-nothing when some items have conflicts or missing parents.

Critique Questions

• Can users tell which deleted object is which before restoring?
• Where exactly will this object return, and can the user access that location?
• What happens if the parent folder, workspace, owner, or permission scope changed?
• How long is the object recoverable, and how is that deadline shown?
• Which actions permanently remove recovery, and are they separated from Restore?
• Does bulk restore report partial success, skipped items, conflicts, and next steps?