UX-WSF-003 — Require an explicit restore destination
| Field | Value |
|---|---|
| Status | Open; source-verified |
| Severity | High |
| Components | sparqd/oqullus, sparqd/workspace-file-management-backend, sparqd/bff-api |
| Associated issues | Not opened |
Concrete observed case
When a user selects Restore, Oqullus derives the presumed original parent from the second-to-last segment of the item's returned path. A deleted file retains its backend folder relationship, but the restore API does not use it as a server-owned default. A deleted folder is detached from its parent and retains the former lineage only indirectly.
Oqullus immediately submits the derived destination. If that request fails for any reason—including a name conflict, lost permission, dependency failure, or network error—the client can retry the user's Home folder and describe the original folder as inaccessible. This can silently change the destination and misstate the cause. The file backend also rejects direct restoration to a workspace root, making that Home fallback invalid for files. The backend accepts an alternate restored name, but Oqullus does not expose it.
Expected condition
Restore opens a confirmation dialog before mutation. The user must confirm:
- a writable destination selected through the authorized folder picker;
- the restored name, with an editable conflict-safe alternative; and
- whether a resolvable original folder is merely the suggested destination.
No automatic second restore is sent after a failed request. Errors preserve the dialog and distinguish destination unavailable, permission denied, name conflict, dependency failure, and retryable transport failure.
Why it matters
Restore is a recovery operation. A silent relocation makes files difficult to find, can place content in an unintended collaboration boundary, and hides the real failure. Retrying a non-idempotent mutation after an ambiguous transport failure can also produce confusing results if the first request committed.
Existing controls and workarounds
The backend validates edit access on the submitted target and prevents active name collisions. Until destination confirmation exists, manually recreate or rename a conflicting destination before Restore, then verify the resulting folder after every attempt.
Alternatives considered
- Recommended: always show a destination-and-name confirmation dialog. The original folder may be preselected only when it resolves and remains writable; it is never submitted without user confirmation.
- Backend-only automatic original-location restore with typed failures—simpler for the client but does not let users recover when the original destination is unsuitable.
- Current automatic original attempt followed by Home retry—rejected because it conflates failures and can relocate content without consent.
Component involvement
- Oqullus owns the destination picker, editable name, confirmation, typed error presentation, and deliberate retry.
- The workspace file backend reports an original-parent hint separately from a path, validates the chosen target and name, and provides conflict-specific responses without choosing a fallback destination.
- BFF API preserves those response distinctions and request identity.
Reproduction and verification
Follow WSF-S008. Exercise files and folders with an available original parent, a conflicting name, revoked target access, a trashed parent, and a one-time transport failure.
Resolution conditions
Close when UI and integration tests prove that no restore request occurs before confirmation, the selected destination and name are honored, every failure retains user input, and no automatic fallback request is emitted.
Validation and blockers
Path-derived targeting, broad-error fallback, root-file rejection, and unused rename support are source-confirmed. Controlled deployed tests for each failure class remain pending.