Repository navigation
Feature request: bulk Restore and Make permanent in the Memories bulk bar #676
Copy link
Copy link
Open
Labels
design-approvedDesign agreed by a maintainer; a PR referencing this issue can be reviewedDesign agreed by a maintainer; a PR referencing this issue can be reviewedfeature requestNew feature or capability requestNew feature or capability request
Description
Short description
The Memories bulk-action bar can archive or delete in bulk but cannot restore or make permanent, although the backend command it already calls supports both.
What problem does this solve?
- Single memory: MemoryDetail's Status dropdown (
active/permanent/archived) already covers restore and permanent. - Bulk: the sticky bulk bar exposes only Archive (
bulkUpdateMemoryStatus(ids, "archived")), Delete, and Clear — which isclearSelection, it only empties the checkbox selection. - Backend:
bulk_update_memory_status(packages/dashboard/src-tauri/src/db.rs) already accepts any status. Its own comments state that a change intoactiveorpermanentcounts as a restore for epoch-bump purposes, and that it only bumps for rows whose status actually changes, so a mixed or no-op selection is safe. - The Archive confirmation even promises the missing capability: "Archived memories are hidden from injection but can be restored later." That is true only one row at a time, through the detail dropdown.
- Friction: after a bulk archive (or a dreamer curate pass archiving stale entries), bringing a set back means opening each memory's detail and changing the dropdown — N round trips for what is one command.
Proposed solution
Add two buttons to the bulk bar next to Archive, mirroring handleBulkArchive's confirm-dialog pattern:
- Restore →
bulkUpdateMemoryStatus(ids, "active") - Make permanent →
bulkUpdateMemoryStatus(ids, "permanent")
No backend work: db::bulk_update_memory_status already handles both statuses, the restore epoch bump, and the no-op guard. Confirm copy mirrors the existing Archive dialog ("Restore N memories? …").
Alternatives considered
- Rely on the single-row Status dropdown: works, but costs one detail open per row after a bulk archive.
- A dedicated archived view with per-row actions: more surface area for the same capability.
Area
Dashboard
Additional context
- Same class of gap as feat(user-memory): restore dismissed memories to the active set (issue 670) #675 (user memories gained a Restore button on dismissed cards); this is the project-memory side, a different table and component.
- Frontend evidence:
packages/dashboard/src/components/MemoryBrowser/MemoryBrowser.tsx(bulk bar: Archive / Delete / Clear) andMemoryDetail.tsx(Status FilterSelect).
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
design-approvedDesign agreed by a maintainer; a PR referencing this issue can be reviewedDesign agreed by a maintainer; a PR referencing this issue can be reviewedfeature requestNew feature or capability requestNew feature or capability request
Activity
magic-alfonso commentedon Oct 13, 2026
Approved, thanks. A pull request is welcome, in the shape you described:
bulkUpdateMemoryStatus(ids, "active")andbulkUpdateMemoryStatus(ids, "permanent").bulk_update_memory_statusalready handles both statuses, the restore epoch bump and the no-op guard.Please reference this issue in the PR description without a closing keyword ("issue 676" rather than "Fixes #676").