File tags, Versioning and activity tracker. #530

Closed
opened 2026-09-14 00:32:37 +00:00 by Cordy · 3 comments
Owner

4 screenshots with 3 new UI elements.
our current preview section could grow and become the actual details pane as well, instead of opening a small window with the details of the file. look at the attached screenshots of the examples of opencloud.
divide this issue into sub-issues if necesarry.

4 screenshots with 3 new UI elements. our current preview section could grow and become the actual details pane as well, instead of opening a small window with the details of the file. look at the attached screenshots of the examples of opencloud. divide this issue into sub-issues if necesarry.
Author
Owner

Read the four OpenCloud screenshots. What they show, mapped to what Cairn has and hasn't:

The container: a persistent details sidebar. All four are the same right-hand pane in different sub-views: an overview (icon/preview, Last modified, Owner, Size, Version count, a Tags input) with drill-in rows for Actions / Shares / Versions / Activities; a per-version list with Restore and Download per entry; an activity timeline ("X updated file in Space, date"); and a shares panel (people search + role, space members with roles, public links). Your instinct that our preview pane could grow into this is sound — the pane already owns the right-hand slot, and the drill-in mechanic matches the admin drill-in we built for #389. On phones this would follow the #389 pattern (takeover or sheet, not a squeezed sidebar).

What exists today vs what's new backend work:

  • Shares panel: mostly recombination — share links, space membership, and (post-#529) the separated federation entry all exist.
  • Activities: no per-file activity feed exists. Ingredients are close: the audit log records actions (runtime toggle, /data/.cairn/audit), the notification feed derives from Inbox + transfers, and recents track access. A per-file feed needs a queryable store + GET /api/v1/activity?path= — decision needed on whether the audit log becomes that store or a separate lighter event log (audit has retention/compliance semantics we may not want to couple to UI).
  • Tags: nothing exists. Needs a store (statestore pattern fits), API, chips in the details pane, and ideally a tag filter in search/browse. Interacts with rename/move/copy (tags must follow the file) — keying needs thought since we have no stable file IDs, only paths.
  • Versioning: the big one, and it's a design problem before it's a feature: version storage per driver (posix + s3/Garage), interaction with encryption (each version is its own age file), quota (versions count?), legal holds (a hold must freeze versions too), retention/GC policy, and WebDAV/WOPI write paths all creating versions consistently. Restore/Download UI is the easy last mile.

Proposed sub-issue split (in build order): 1) details-pane shell — grow the preview pane into the sidebar with overview + drill-ins, wiring only what exists (metadata, shares); 2) file activities (event store + API + timeline panel); 3) tags (store + API + UI + filter); 4) file versioning (design/ADR first, then storage, then UI). Each gets its own mockup per house rules; 1 can ship without 2–4 (rows appear as backends land).

Happy to open the sub-issues in that shape — say the word. One question: should the details pane replace the current small details window entirely (one surface, per OpenCloud), or keep the dialog for phone and grow the pane on desktop only?

Read the four OpenCloud screenshots. What they show, mapped to what Cairn has and hasn't: **The container: a persistent details sidebar.** All four are the same right-hand pane in different sub-views: an overview (icon/preview, Last modified, Owner, Size, Version count, a **Tags** input) with drill-in rows for Actions / Shares / Versions / Activities; a per-version list with Restore and Download per entry; an activity timeline ("X updated file in Space, date"); and a shares panel (people search + role, space members with roles, public links). Your instinct that our preview pane could grow into this is sound — the pane already owns the right-hand slot, and the drill-in mechanic matches the admin drill-in we built for #389. On phones this would follow the #389 pattern (takeover or sheet, not a squeezed sidebar). **What exists today vs what's new backend work:** - *Shares panel:* mostly recombination — share links, space membership, and (post-#529) the separated federation entry all exist. - *Activities:* no per-file activity feed exists. Ingredients are close: the audit log records actions (runtime toggle, `/data/.cairn/audit`), the notification feed derives from Inbox + transfers, and recents track access. A per-file feed needs a queryable store + `GET /api/v1/activity?path=` — decision needed on whether the audit log becomes that store or a separate lighter event log (audit has retention/compliance semantics we may not want to couple to UI). - *Tags:* nothing exists. Needs a store (statestore pattern fits), API, chips in the details pane, and ideally a tag filter in search/browse. Interacts with rename/move/copy (tags must follow the file) — keying needs thought since we have no stable file IDs, only paths. - *Versioning:* the big one, and it's a **design problem before it's a feature**: version storage per driver (posix + s3/Garage), interaction with encryption (each version is its own age file), quota (versions count?), legal holds (a hold must freeze versions too), retention/GC policy, and WebDAV/WOPI write paths all creating versions consistently. Restore/Download UI is the easy last mile. **Proposed sub-issue split** (in build order): 1) details-pane shell — grow the preview pane into the sidebar with overview + drill-ins, wiring only what exists (metadata, shares); 2) file activities (event store + API + timeline panel); 3) tags (store + API + UI + filter); 4) file versioning (design/ADR first, then storage, then UI). Each gets its own mockup per house rules; 1 can ship without 2–4 (rows appear as backends land). Happy to open the sub-issues in that shape — say the word. One question: should the details pane replace the current small details window entirely (one surface, per OpenCloud), or keep the dialog for phone and grow the pane on desktop only?
Author
Owner

Split approved by Nikola — sub-issues opened, this becomes the tracking issue:

  • #538 — details pane shell (grow the preview pane; mockup first)
  • #539 — per-file activity feed (event store + API + timeline)
  • #540 — file tags (store + API + chips + filter)
  • #541 — file versioning (ADR first, then storage + restore/download UI)

Build order 538 → 539/540 → 541; the shell ships without the others and grows rows as backends land.

Split approved by Nikola — sub-issues opened, this becomes the tracking issue: - #538 — details pane shell (grow the preview pane; mockup first) - #539 — per-file activity feed (event store + API + timeline) - #540 — file tags (store + API + chips + filter) - #541 — file versioning (ADR first, then storage + restore/download UI) Build order 538 → 539/540 → 541; the shell ships without the others and grows rows as backends land.
Cordy closed this issue 2026-09-22 18:55:18 +00:00
Author
Owner

Closing: all four sub-issues shipped — #538 (details pane shell), #539 (per-file activity feed), #540 (file tags), #541 (versioning, ADR + storage + restore/download UI). The pane has since been refined further through the pane-v2 fidelity work (v0.6.230–241), and tag search landed in v0.6.241.

Closing: all four sub-issues shipped — #538 (details pane shell), #539 (per-file activity feed), #540 (file tags), #541 (versioning, ADR + storage + restore/download UI). The pane has since been refined further through the pane-v2 fidelity work (v0.6.230–241), and tag search landed in v0.6.241.
Sign in to join this conversation.
No labels
No project
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#530
No description provided.