Orphan space folders: "Assign a new owner" — hand an unmanaged folder to any user, not just the acting admin #719

New issue

Open

opened 2026-09-24 04:32:36 +00:00 by Cordy · 0 comments

Cordy commented

2026-09-24 04:32:36 +00:00

Owner

Follow-up to #715/#717, per Nikola's decision during the dogfood cleanup (2026-09-24).

Context: with #715, a /spaces folder that matches no app-owned record and no directory group the IdP knows reads "Folder in storage — no managing group found". #717 added the cleanup path (Take over and deactivate → standard delete lifecycle). This issue covers the keep path.

Idea: this state should be rare-to-never after #690 removed group synthesis — but if a folder ever falls into it at a customer (IdP group deleted, storage migration, manual dir), the admin should be able to rescue it, not only clean it up. The orphan row's menu gains "Assign a new owner": a dialog with a user picker (same candidates idiom as the space member picker, degrading to free-text without an enumerable source). Confirming creates the app-owned record with the chosen user as owner — the folder becomes a normal Owned by <user> · app-managed space, active, with the full lifecycle and member management.

Notes for the design round:

Reuses the existing create+record machinery; the only new surface is the dialog and an owner override on creation (POST /api/v1/spaces currently hardcodes the caller as owner — needs an admin-only owner field or a dedicated admin endpoint).
Dialog follows the house canon (field + candidates datalist, primary action "Assign owner").
Audit as space-create with the assigned owner, or a dedicated space-assign-owner verb — decide in design.
Tombstoned names surface the existing "reserved" refusal.

Low priority: edge case by construction; #717 already covers the destructive path.

Follow-up to #715/#717, per Nikola's decision during the dogfood cleanup (2026-09-24). **Context:** with #715, a `/spaces` folder that matches no app-owned record and no directory group the IdP knows reads "Folder in storage — no managing group found". #717 added the cleanup path (Take over and deactivate → standard delete lifecycle). This issue covers the *keep* path. **Idea:** this state should be rare-to-never after #690 removed group synthesis — but if a folder ever falls into it at a customer (IdP group deleted, storage migration, manual dir), the admin should be able to rescue it, not only clean it up. The orphan row's menu gains **"Assign a new owner"**: a dialog with a user picker (same candidates idiom as the space member picker, degrading to free-text without an enumerable source). Confirming creates the app-owned record with the chosen user as owner — the folder becomes a normal `Owned by <user> · app-managed` space, active, with the full lifecycle and member management. **Notes for the design round:** - Reuses the existing create+record machinery; the only new surface is the dialog and an owner override on creation (`POST /api/v1/spaces` currently hardcodes the caller as owner — needs an admin-only `owner` field or a dedicated admin endpoint). - Dialog follows the house canon (field + candidates datalist, primary action "Assign owner"). - Audit as `space-create` with the assigned owner, or a dedicated `space-assign-owner` verb — decide in design. - Tombstoned names surface the existing "reserved" refusal. Low priority: edge case by construction; #717 already covers the destructive path.