Checking who may restore a deleted object and its former permissions

Goal

Treat restoring a deleted object as a new authorization decision with explicit permission semantics. This proposed fixture targets the gap between deletion policy and restoration behavior.

Prerequisites

Use a disposable application with reversible deletion, synthetic owners, and a sharing relationship. Decide whether restoration preserves, removes, or revalidates the object’s former grants.

Steps

1. Create a shared synthetic object and verify the owner and recipient controls. Record the exact intended visibility before deletion without relying on interface labels alone.

2. Delete the object through the owner’s allowed path. Verify the documented visibility during deletion for ordinary retrieval, listings, and the application’s restoration interface.

3. Attempt restoration as an unrelated synthetic account and as the former recipient. Compare each result with the explicit restore policy and inspect stored state after rejected attempts.

4. Restore through the authorized path, then recheck former recipients independently. A restored object’s existence does not by itself decide whether its old sharing grants should return.

5. Change a relevant membership before a separate restoration and repeat the checks. Preserve the selected revalidation semantics as a regression rather than silently inheriting whatever old metadata contains.

Expected result

The evidence should distinguish permission to restore from permission to read the restored object, with a clear account of which earlier grants remain effective.

Limits and test basis

This method covers logical deletion and restoration within the application. It does not establish physical erasure, storage retention guarantees, or the correctness of external backup restoration. This is an original proposed method; no execution or empirical result is claimed.