#286: Space lifecycle — Deactivate → Delete, contents to trash, name tombstone (v0.6.54) #289
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/space286"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Implements the #268 decisions, per the signed-off mockup. Fixes the dogfood finding that a space owner had no way to delete their space.
spacestore
SpacegainsDeactivated/DeletedAt/KeepUntil.RoleFor: deactivated → owner-only read; tombstoned → nothing.SpacesForUser: members lose deactivated spaces, the owner keeps them; tombstones vanish. Since scope.go consumes exactly these two functions, visibility filtering needs zero scope changes.SetDeactivated(reversible),DeleteTombstone(refuses non-deactivated withErrActive, clears members, reserves the name until keepUntil).Createrefuses tombstoned names (ErrTombstoned) until expiry — closes the name-reuse resurrection pitfall.newStoreharness.API (owner-or-admin; app-owned only, 501 on IdP-managed)
GET /api/v1/spaces(manageable spaces + retentionDays),GET …/{name}/state,POST …/deactivate|reactivate,DELETE /api/v1/spaces/{name}./spaces/<name>into the caller's trash as one recoverable entry (a hold inside refuses the move and aborts — hold.Wrap sits outside trash in the stack), tombstones for the retention window (trashAutoPurgeAfter, 90d fallback, wired in main.go). Audited:space-deactivate/space-reactivate/space-delete.UI (fidelity-diffed against the mockup)
Known edges (documented): restoring the trashed space folder restores files, not membership (the tombstone still blocks recreation); an early manual purge does not shorten the name reservation.