mirror of
https://github.com/multica-ai/multica.git
synced 2026-07-29 06:28:23 +02:00
6b2097ccbb
Adds an "Archived" sub-view to the Inbox, reachable from an entry at the
bottom of the main list, with per-row unarchive. Mirrors chat's archived
sub-view so the two surfaces share one mental model.
Backend:
- GET /api/inbox/archived and POST /api/inbox/{id}/unarchive. Kept off the
existing GET /api/inbox so installed clients keep their contract and the
unbounded archive never rides along with the main list.
- The archived query excludes any issue that still has an active row. Archiving
is issue-level, so a new notification on an archived issue leaves old archived
rows beside a fresh active one — without the guard the issue renders in BOTH
lists. The exclusion lives in SQL so neither list depends on the other's cache.
- Unarchive is issue-level (mirroring archive) and leaves `read` untouched, so a
restored unread item raises the unread badge again.
- v1 ships no pagination: LIMIT 200, newest-first, so truncation drops the
oldest rows and never hides a group's newest one.
- inbox:unarchived event, fanned out to the recipient like the other personal
inbox events.
- Two CONCURRENTLY-built indexes; inbox_item previously had none covering
workspace/archived/created_at.
Frontend:
- Separate TanStack cache per list; every inbox event invalidates the workspace
prefix, since any of them can move an item across the boundary.
- View persisted as ?view=archived, so refresh, back/forward, and the mobile
detail-back all return to the list the user was in.
- Batch actions stay main-view only — they archive from the MAIN inbox, so
offering them over the archived list would do the opposite of what it reads.
- Mobile subscribes to inbox:unarchived (its list gains the restored row); its
own archived view remains follow-up.
Known debt: no pagination, so an archive past ~200 rows is truncated silently
in the UI; the entry's count is the deduplicated count of the rows returned.
Verified: pnpm typecheck/test/lint (0 errors), go build/vet, Go inbox suite
against a real Postgres, migrations up+down, and EXPLAIN confirming both new
indexes serve the query.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: multica-agent <github@multica.ai>
16 lines
685 B
TypeScript
16 lines
685 B
TypeScript
/**
|
|
* Which of the inbox's two lists is showing.
|
|
*
|
|
* "inbox" is the default list of active notifications; "archived" is the
|
|
* sub-view reached from the entry at the bottom of that list. The two are
|
|
* mutually exclusive per issue — the server decides which list an issue
|
|
* belongs to (see ListArchivedInboxItems) — so a view is a complete swap of
|
|
* the list's data source and row action, not a filter layered on one list.
|
|
*
|
|
* Persisted in the URL as `?view=archived` so a refresh, a back/forward step,
|
|
* or a mobile detail-back returns to the list the user was actually in.
|
|
*/
|
|
export type InboxView = "inbox" | "archived";
|
|
|
|
export const ARCHIVED_VIEW_PARAM = "archived";
|