Cordy/Cairn
2
1
Fork 0
Code Issues 20 Pull requests Projects Releases Packages Wiki Activity Actions

Space deletion: Deactivate → Delete, contents to trash, name tombstone (#268 decisions) #286

New issue
Closed
opened 2026-08-19 21:02:51 +00:00 by Cordy · 4 comments
Cordy commented 2026-08-19 21:02:51 +00:00
Owner
Copy link

Dogfood finding (2026-08-19, v0.6.51): the owner of a space (e.g. Fall 3) tries to delete it from the Spaces file listing and gets "Spaces are managed containers and cannot be deleted from the file listing." That guard is correct — but there is currently no way to delete a space at all: spacestore.Delete exists but is metadata-only and nothing exposes it. This issue implements the lifecycle decided in #268.

Decided model (#268, 2026-08-18):

  • Deactivate → Delete, two deliberate steps. Deactivate hides the space from members (owner + admins still see it, read-only) and is reversible. Delete is only offered on a deactivated space.
  • Delete moves the space's contents to trash under the normal trash-retention window — recoverable via Manual purge / restore until the window runs out or an admin purges. Legal holds and retention windows on paths inside the space block final deletion exactly as everywhere else.
  • Name tombstone: the space name stays reserved for the trash-retention window (= the tombstone window, one knob). Prevents the name-reuse resurrection pitfall (per-name group keys: a recreated space with the same name must not inherit the old key or old trashed content).
  • Group key retires at final purge, not at delete.

Implementation sketch:

  • spacestore: Deactivate(name) / Reactivate(name) flags + Delete(name) grows the content move (space tree → trash entries) and writes the tombstone {name, deletedAt, keepUntil}; Create refuses tombstoned names with a clear error.
  • API: POST /api/v1/spaces/{name}/deactivate, POST /api/v1/spaces/{name}/reactivate, DELETE /api/v1/spaces/{name} — all ownerOrAdmin, all audited (space-deactivate, space-delete).
  • Scope/route A: if IdP group bindings exist, deactivation must not delete IdP groups (route A demoted to opt-in per #268); stale peering recvSpaces must tolerate a deactivated/deleted space (listed pitfall).
  • UI (mockup-first, per house process): Spaces management page gets per-space Deactivate / Delete with a confirmation dialog in the v0.6.52 style (contents summary, retention note, red confirm); the file-listing guard message gains "manage spaces on the Spaces page" pointing at the real flow.
  • Docs: sharp-edge note — backup story vs. tombstones (from #268 corollaries).

Out of scope: key rotation on reactivation; bulk space archival.

**Dogfood finding (2026-08-19, v0.6.51):** the owner of a space (e.g. `Fall 3`) tries to delete it from the Spaces file listing and gets "Spaces are managed containers and cannot be deleted from the file listing." That guard is correct — but there is currently **no way to delete a space at all**: `spacestore.Delete` exists but is metadata-only and nothing exposes it. This issue implements the lifecycle decided in #268. **Decided model (#268, 2026-08-18):** - **Deactivate → Delete**, two deliberate steps. Deactivate hides the space from members (owner + admins still see it, read-only) and is reversible. Delete is only offered on a deactivated space. - **Delete moves the space's contents to trash** under the normal trash-retention window — recoverable via Manual purge / restore until the window runs out or an admin purges. Legal holds and retention windows on paths inside the space block final deletion exactly as everywhere else. - **Name tombstone:** the space name stays reserved for the trash-retention window (= the tombstone window, one knob). Prevents the name-reuse resurrection pitfall (per-name group keys: a recreated space with the same name must not inherit the old key or old trashed content). - **Group key retires at final purge**, not at delete. **Implementation sketch:** - `spacestore`: `Deactivate(name)` / `Reactivate(name)` flags + `Delete(name)` grows the content move (space tree → trash entries) and writes the tombstone `{name, deletedAt, keepUntil}`; `Create` refuses tombstoned names with a clear error. - API: `POST /api/v1/spaces/{name}/deactivate`, `POST /api/v1/spaces/{name}/reactivate`, `DELETE /api/v1/spaces/{name}` — all `ownerOrAdmin`, all audited (`space-deactivate`, `space-delete`). - Scope/route A: if IdP group bindings exist, deactivation must not delete IdP groups (route A demoted to opt-in per #268); stale peering `recvSpaces` must tolerate a deactivated/deleted space (listed pitfall). - UI (mockup-first, per house process): Spaces management page gets per-space Deactivate / Delete with a confirmation dialog in the v0.6.52 style (contents summary, retention note, red confirm); the file-listing guard message gains "manage spaces on the Spaces page" pointing at the real flow. - Docs: sharp-edge note — backup story vs. tombstones (from #268 corollaries). **Out of scope:** key rotation on reactivation; bulk space archival.
Cordy commented 2026-08-19 22:11:28 +00:00
Author
Owner
Copy link

Shipped as v0.6.54 (PR #289), live on both dogfoods. Built exactly on the #268 decisions; lifecycle tests (deactivate/reactivate roles + visibility, tombstone blocking + expiry) green in CI.

How it works:

  • ⋯ menu on a space row (/spaces listing, owner or admin): Details, then Deactivate space — reversible; the space vanishes for members while the owner keeps read-only sight (admins see everything via the unscoped view). A deactivated space's menu offers Reactivate and the red Delete space….
  • Delete opens the confirmation dialog (contents → Deleted files for the retention window; name reserved; holds protection), then moves /spaces/<name> into the deleting user's trash as one recoverable entry (visible in Admin → Deleted files → Manual purge) and tombstones the record.
  • Recreating the name before the reservation expires → 409 "reserved by a recently deleted space".
  • Audit: space-deactivate, space-reactivate, space-delete.

Known edges (accepted v1): restoring the trashed space folder restores files only, not membership — the tombstone still blocks recreating the space until expiry; an early manual purge doesn't shorten the name reservation; IdP-managed (route A) spaces answer 501 on lifecycle routes. Deviation from the mockup: no "deactivated" pill on the listing row yet — the state shows in the menu; pill is a candidate for a follow-up polish once row decoration is scouted.

Dogfood checklist (fresh login):

  1. ⋯ on a test space → Deactivate → space disappears for a member account (e.g. bao-side user), still listed read-only for you
  2. Reactivate → member access restored (member may need re-login for session-cached groups)
  3. Deactivate → Delete → dialog shows retention days → space gone, one big entry in Manual purge owned by you
  4. Try creating a space with the same name → refused with the reservation message
  5. Deleting from the file listing still guards, now pointing at the ⋯ menu
Shipped as **v0.6.54** (PR #289), live on both dogfoods. Built exactly on the #268 decisions; lifecycle tests (deactivate/reactivate roles + visibility, tombstone blocking + expiry) green in CI. **How it works:** - ⋯ menu on a space row (`/spaces` listing, owner or admin): Details, then **Deactivate space** — reversible; the space vanishes for members while the owner keeps read-only sight (admins see everything via the unscoped view). A deactivated space's menu offers **Reactivate** and the red **Delete space…**. - Delete opens the confirmation dialog (contents → Deleted files for the retention window; name reserved; holds protection), then moves `/spaces/<name>` into the deleting user's trash as **one recoverable entry** (visible in Admin → Deleted files → Manual purge) and tombstones the record. - Recreating the name before the reservation expires → 409 "reserved by a recently deleted space". - Audit: `space-deactivate`, `space-reactivate`, `space-delete`. **Known edges (accepted v1):** restoring the trashed space folder restores files only, not membership — the tombstone still blocks recreating the space until expiry; an early manual purge doesn't shorten the name reservation; IdP-managed (route A) spaces answer 501 on lifecycle routes. Deviation from the mockup: no "deactivated" pill on the listing row yet — the state shows in the menu; pill is a candidate for a follow-up polish once row decoration is scouted. **Dogfood checklist (fresh login):** 1. ⋯ on a test space → Deactivate → space disappears for a member account (e.g. bao-side user), still listed read-only for you 2. Reactivate → member access restored (member may need re-login for session-cached groups) 3. Deactivate → Delete → dialog shows retention days → space gone, one big entry in Manual purge owned by you 4. Try creating a space with the same name → refused with the reservation message 5. Deleting from the file listing still guards, now pointing at the ⋯ menu
Cordy commented 2026-09-03 02:08:29 +00:00
Author
Owner
Copy link

UI polish round decided (2026-09-03, operator review of the shipped lifecycle; mockups in space-lifecycle-ui-mockup.html):

  1. Delete dialog → variant A2 (consequence list + type-to-confirm). Space name in the title in normal type (no mono/colour); the three consequences become icon rows — contents to Deleted files, name tombstone, holds/retention protection; the danger button stays disabled until the space name is typed back (matches the admin inventory's name confirmation). Retention copy is dynamic, from the live trash settings: auto-purge on → "Recoverable for {n} days, then removed by the normal sweep"; auto-purge off (the default) → "Recoverable until an administrator purges them — nothing is removed automatically". The tombstone row states the same window. A user must never read "90 days" when the admin set 30 — or set never.
  2. Spaces listing → variant B2 (deactivated group). Active spaces list first; deactivated ones sink under an amber "Deactivated" divider, rows dimmed with an amber chip and the sub-line "Hidden from members · you keep view-only access" replacing the item count. The row visibly moving down on deactivation is the immediate feedback. Footer gains "· N space(s) deactivated". Amber = reversible; red stays destruction-only.
  3. Inside a deactivated space → variant C. The breadcrumb's bare "View only" gains a sibling amber "Deactivated" chip (cause + effect), and owners/admins see a one-line banner — "This space is deactivated. Members cannot see it; nothing was deleted." — with an inline Reactivate button, so undoing doesn't require re-finding the ⋯ menu. Members see nothing (the space is hidden for them anyway).

Backend note: the /spaces listing rows and the in-space listing response need a deactivated flag stamped from the spacestore (fillLocks-style enrichment, no N+1); everything else is frontend + i18n ×4.

**UI polish round decided (2026-09-03, operator review of the shipped lifecycle; mockups in `space-lifecycle-ui-mockup.html`):** 1. **Delete dialog → variant A2 (consequence list + type-to-confirm).** Space name in the title in normal type (no mono/colour); the three consequences become icon rows — contents to Deleted files, name tombstone, holds/retention protection; the danger button stays disabled until the space name is typed back (matches the admin inventory's name confirmation). **Retention copy is dynamic**, from the live trash settings: auto-purge on → "Recoverable for {n} days, then removed by the normal sweep"; auto-purge off (the default) → "Recoverable until an administrator purges them — nothing is removed automatically". The tombstone row states the same window. A user must never read "90 days" when the admin set 30 — or set never. 2. **Spaces listing → variant B2 (deactivated group).** Active spaces list first; deactivated ones sink under an amber "Deactivated" divider, rows dimmed with an amber chip and the sub-line "Hidden from members · you keep view-only access" replacing the item count. The row visibly moving down on deactivation is the immediate feedback. Footer gains "· N space(s) deactivated". Amber = reversible; red stays destruction-only. 3. **Inside a deactivated space → variant C.** The breadcrumb's bare "View only" gains a sibling amber "Deactivated" chip (cause + effect), and owners/admins see a one-line banner — "This space is deactivated. Members cannot see it; nothing was deleted." — with an inline **Reactivate** button, so undoing doesn't require re-finding the ⋯ menu. Members see nothing (the space is hidden for them anyway). Backend note: the `/spaces` listing rows and the in-space listing response need a `deactivated` flag stamped from the spacestore (fillLocks-style enrichment, no N+1); everything else is frontend + i18n ×4.
Cordy referenced this issue from a commit 2026-09-03 02:09:16 +00:00
scout: #286 UI polish anchors
Cordy commented 2026-09-03 02:31:02 +00:00
Author
Owner
Copy link

UI polish round shipped — v0.6.114 (PR #407), live on both dogfoods.

  • A2 delete dialog: consequence rows with icons, name in the title in normal type, type-the-name-to-confirm gating the danger button. The recoverability line is dynamic and honest: configured retention window when the sweep is on, "recoverable until an administrator purges them — nothing is removed automatically" when it's off (the default). New neverPurge field on GET /api/v1/spaces/{name}/state.
  • B2 listing: deactivated stamped on /spaces rows (fillSpaceStates, in-memory, owner/admin-only by construction); deactivated spaces sink below an amber "Deactivated" divider, dimmed, amber chip, "Hidden from members · you keep view-only access" sub-line; footer counts them.
  • C in-space: listing response gains spaceDeactivated; amber "Deactivated" chip beside "View only" in the crumb, plus a banner with inline Reactivate.

Dogfood checklist (fresh login — in-memory sessions):

  1. ⋯ on a deactivated-able space → Deactivate → row moves under the amber divider, dimmed, chip + sub-line; footer shows "· 1 space deactivated"
  2. Open the deactivated space → amber chip next to "View only" + banner; press Reactivate inline → space returns to the active group
  3. Deactivate again → ⋯ → Delete space → new dialog: three icon rows, danger button disabled until you type the exact name; check the first row's wording matches your Deleted-files setting (with "Never delete automatically" on it must say "until an administrator purges them")
  4. Grid view: deactivated tiles render dimmed
  5. All four languages on the dialog + banner (Appearance → language)
**UI polish round shipped — v0.6.114 (PR #407), live on both dogfoods.** - **A2 delete dialog:** consequence rows with icons, name in the title in normal type, type-the-name-to-confirm gating the danger button. The recoverability line is dynamic and honest: configured retention window when the sweep is on, "recoverable until an administrator purges them — nothing is removed automatically" when it's off (the default). New `neverPurge` field on `GET /api/v1/spaces/{name}/state`. - **B2 listing:** `deactivated` stamped on `/spaces` rows (`fillSpaceStates`, in-memory, owner/admin-only by construction); deactivated spaces sink below an amber "Deactivated" divider, dimmed, amber chip, "Hidden from members · you keep view-only access" sub-line; footer counts them. - **C in-space:** listing response gains `spaceDeactivated`; amber "Deactivated" chip beside "View only" in the crumb, plus a banner with inline **Reactivate**. **Dogfood checklist (fresh login — in-memory sessions):** 1. ⋯ on a deactivated-able space → Deactivate → row moves under the amber divider, dimmed, chip + sub-line; footer shows "· 1 space deactivated" 2. Open the deactivated space → amber chip next to "View only" + banner; press **Reactivate** inline → space returns to the active group 3. Deactivate again → ⋯ → Delete space → new dialog: three icon rows, danger button disabled until you type the exact name; check the first row's wording matches your Deleted-files setting (with "Never delete automatically" on it must say "until an administrator purges them") 4. Grid view: deactivated tiles render dimmed 5. All four languages on the dialog + banner (Appearance → language)
Cordy commented 2026-09-03 02:39:42 +00:00
Author
Owner
Copy link

Operator visual pass complete on the live dogfood (2026-09-03, v0.6.114) — all checklist items passed. With that, the full #286 arc is done: lifecycle shipped v0.6.54, admin inventory wired in the #311 sweep, and the UI polish round (A2 dialog with honest retention copy + name confirm, B2 deactivated group, C in-space banner) verified in use. Closing.

Operator visual pass complete on the live dogfood (2026-09-03, v0.6.114) — all checklist items passed. With that, the full #286 arc is done: lifecycle shipped v0.6.54, admin inventory wired in the #311 sweep, and the UI polish round (A2 dialog with honest retention copy + name confirm, B2 deactivated group, C in-space banner) verified in use. Closing.
Cordy closed this issue 2026-09-03 02:39:47 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
fix-escguard
fix-vard
fix-middot
fix-552d
fix-552c
fix-543
scout-tf
v0.6.265
v0.6.264
v0.6.263
v0.6.262
v0.6.261
v0.6.260
v0.6.259
v0.6.258
v0.6.257
v0.6.256
v0.6.255
v0.6.254
v0.6.253
v0.6.252
v0.6.251
v0.6.250
v0.6.249
v0.6.248
v0.6.247
v0.6.246
v0.6.245
v0.6.244
v0.6.243
v0.6.242
v0.6.241
v0.6.240
v0.6.239
v0.6.238
v0.6.237
v0.6.236
v0.6.235
v0.6.234
v0.6.233
v0.6.232
v0.6.231
v0.6.230
v0.6.229
v0.6.228
v0.6.227
v0.6.226
v0.6.225
v0.6.224
v0.6.223
v0.6.222
v0.6.221
v0.6.220
v0.6.219
v0.6.218
v0.6.217
v0.6.216
v0.6.215
v0.6.214
v0.6.213
v0.6.212
v0.6.211
v0.6.210
v0.6.209
v0.6.208
v0.6.207
v0.6.206
v0.6.205
v0.6.204
v0.6.203
v0.6.202
v0.6.201
v0.6.200
v0.6.199
v0.6.198
v0.6.197
v0.6.196
v0.6.195
v0.6.194
v0.6.193
v0.6.192
v0.6.191
v0.6.190
v0.6.189
v0.6.188
v0.6.187
v0.6.186
v0.6.185
v0.6.184
v0.6.183
v0.6.182
v0.6.181
v0.6.180
v0.6.179
v0.6.178
v0.6.177
v0.6.176
v0.6.175
v0.6.174
v0.6.173
v0.6.172
v0.6.171
v0.6.170
v0.6.169
v0.6.168
v0.6.167
v0.6.166
v0.6.165
v0.6.164
v0.6.163
v0.6.162
v0.6.161
v0.6.160
v0.6.159
v0.6.158
v0.6.157
v0.6.156
v0.6.155
v0.6.154
v0.6.153
v0.6.152
v0.6.151
v0.6.150
v0.6.149
v0.6.148
v0.6.147
v0.6.146
v0.6.145
v0.6.144
v0.6.143
v0.6.142
v0.6.141
v0.6.140
v0.6.139
v0.6.138
v0.6.137
v0.6.136
v0.6.135
v0.6.134
v0.6.133
v0.6.132
v0.6.131
v0.6.130
v0.6.129
v0.6.128
v0.6.127
v0.6.126
v0.6.125
v0.6.124
v0.6.123
v0.6.122
v0.6.121
v0.6.120
v0.6.119
v0.6.118
v0.6.117
v0.6.116
v0.6.115
v0.6.114
v0.6.113
v0.6.112
v0.6.111
v0.6.110
v0.6.109
v0.6.108
v0.6.107
v0.6.106
v0.6.105
v0.6.104
v0.6.103
v0.6.102
v0.6.101
v0.6.100
v0.6.99
v0.6.98
v0.6.97
v0.6.96
v0.6.95
v0.6.94
v0.6.93
v0.6.92
v0.6.91
v0.6.90
v0.6.89
v0.6.88
v0.6.87
v0.6.86
v0.6.85
v0.6.84
v0.6.83
v0.6.82
v0.6.81
v0.6.80
v0.6.79
v0.6.78
v0.6.77
v0.6.76
v0.6.75
v0.6.74
v0.6.73
v0.6.72
v0.6.71
v0.6.70
v0.6.69
v0.6.68
v0.6.67
v0.6.66
v0.6.65
v0.6.64
v0.6.63
v0.6.62
v0.6.61
v0.6.60
v0.6.59
v0.6.58
v0.6.57
v0.6.56
v0.6.55
v0.6.54
v0.6.53
v0.6.52
v0.6.51
v0.6.50
v0.6.49
v0.6.48
v0.6.47
v0.6.46
v0.6.45
v0.6.44
v0.6.43
v0.6.42
v0.6.41
v0.6.40
v0.6.39
v0.6.38
v0.6.37
v0.6.36
v0.6.35
v0.6.34
v0.6.33
v0.6.32
v0.6.31
v0.6.30
v0.6.29
v0.6.28
v0.6.25
v0.6.24
v0.6.23
v0.6.22
v0.6.21
v0.6.20
v0.6.19
v0.6.18
v0.6.17
v0.6.16
v0.6.15
v0.6.14
v0.6.12
v0.6.11
v0.6.10
v0.6.9
v0.6.8
v0.6.7
v0.6.6
v0.6.5
v0.6.4
v0.6.3
v0.6.2
v0.6.1
v0.6.0
v0.5.7
v0.5.6
v0.5.5
v0.5.4
v0.5.3
v0.5.2
v0.5.1
v0.5.0
v0.4.12
v0.4.11
v0.4.10
v0.4.9
v0.4.8
v0.4.7
v0.4.6
v0.4.5
v0.4.4
v0.4.3
v0.4.2
v0.4.1
v0.3.30
v0.3.29
v0.3.28
v0.3.27
v0.3.26
v0.3.25
v0.3.24
v0.3.23
v0.3.22
v0.3.21
v0.3.20
v0.3.19
v0.3.18
v0.3.17
v0.3.16
v0.3.15
v0.3.14
v0.3.13
v0.3.12
v0.3.11
v0.3.10
v0.3.9
v0.3.8
v0.3.7
v0.3.6
v0.3.5
v0.3.4
v0.3.3
v0.3.2
v0.3.1
v0.3.0
v0.2.7
v0.2.6
v0.2.5
v0.2.4
v0.2.3
v0.2.2
v0.2.1
v0.2.0
v0.0.3
v0.0.2
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
v0.7 — Closed beta (dogfood + hardening)
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Cordy/Cairn#286
No description provided.
Delete branch "%!s()"

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?