Feature request: bring back a local sync/transfer history view (34.x Activity window only shows own actions)
- Dominant language
- C++
- Stars
- 3.9k
- Forks
- 1k
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 123
Description
### How to use GitHub
* Please use the 👍 reaction to show you're interested in the same feature.
* Please don't comment if you have no relevant information to add.
* Subscribe to receive notifications on status change and new comments.
---
## Feature request
**Which Nextcloud Desktop client version are you using:** 34.0.3
**Server version:** 33.0.8.2
**Activity app:** 6.0.0
**Groupfolders/Team folders:** 21.0.15
**Platforms affected:** Windows (confirmed) and macOS (confirmed by a colleague on the same server)
**Is your feature request related to a problem? Please describe.**
Since upgrading from Desktop 33.x to 34.x, there is no longer any way to see a
chronological, locally-observable history of files actually transferred
to/from this machine. This is not a minor UX complaint about click count —
it's a daily-use feature our whole team relied on and is now gone.
Under 33.x, the tray flyout's activity list let us watch, in real time, which
files had actually arrived on the local disk or been re-downloaded after a
remote change. Concrete daily workflows this supported:
* A scanner drops new PDFs onto Nextcloud. They typically appear locally
5 seconds to several minutes later. The activity list told us exactly when
a given file had actually landed on disk.
* A colleague changes a shared file. We could watch the activity list to see
when that specific change was actually pulled down to our machine — not
just that a sync round finished at some point.
* After booting the machine, sync can run for 5–30 minutes. The activity
list was the reliable way to tell whether transfers were still ongoing and
when a full sync run had actually completed — the tray's green checkmark
can appear green mid-way through, before further files are transferred.
In 34.x, the equivalent surface is **Tray → account → "More activity"**, a
separate window. This window shows essentially only activity **triggered by
the local user** (e.g. files renamed/deleted locally). It does **not** show:
* files downloaded from the server as a result of remote changes
* files updated locally after another user changed them
* a chronological, ongoing list of what has actually synced to this machine
* a reliable signal of whether a sync round is still in progress or has
just finished
**To be clear — this is not a request for server-side Activity.** We are not
asking to see "User X changed file Y" (that's already available via the
Activity app / `activity_use_cached_mountpoints`). We need the *local*
event: "file Y has now actually been synced to this machine", which can lag
the server-side event by anywhere from seconds to minutes:
```
09:00:00 – file created/changed on server (by scanner or colleague)
09:00:10 – server records the change
09:02:30 – desktop client actually downloads it locally
```
09:02:30 is the timestamp that matters for our workflow; none of the
suggested server-activity settings surface it.
**Describe the solution you'd like**
Restore a view — ideally within the new Activities window, doesn't need to
be the old flyout specifically — that shows the local transfer log:
* file name/path
* direction (download/upload)
* local timestamp of the actual sync
* whether a sync is currently in progress
* a clear signal when a full sync run has completed
**Describe alternatives you've considered**
* The green tray icon / sync status is not sufficient: it can show "synced"
while further files are still being transferred behind it, so it doesn't
answer "is file Y here yet" or "is the whole run actually done".
* Server-side Activity settings (`activity_use_cached_mountpoints` etc.)
don't help — they surface server-side events, not local-arrival events,
and the two can be minutes apart (see example above).
**Additional context**
This looks related to the tray/activity rework in #10164, previously raised
in #10475 (closed — that thread focused on click-count/menu-depth, and the
maintainer response there was that the old flyout itself won't return). This
request is narrower and doesn't ask for the flyout back: it's about the
*content* gap — the new Activities window doesn't expose the local
transfer/arrival history at all, regardless of which window or menu depth
hosts it.
Related but distinct: #10563 (visibility gap for failed uploads on macOS
File Provider) — that's about surfacing failures; this request is about the
baseline chronological arrival log for successful transfers.
For teams like ours (shared/group folders with frequent external drops —
scanners, colleagues — and machines that sync large backlogs after being
offline), this local arrival visibility is used multiple times daily by
every team member. It's not a nice-to-have; without it, we have no reliable
way to know whether/when a file we're waiting on has actually arrived, or
whether a sync run has genuinely finished.
Contributor guide
Research direction
The issue does not name files, tests, or a code entry point. Start by tracing the 34.x Tray → account → “More activity” window and the existing local sync status reporting. Done should include a chronological local transfer view with file path, direction, local timestamp, in-progress status, and a clear full-sync completion signal.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- desktop
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100