🔧 PUT-1590: Mark shared items in the file listings - #3646
Merged
jfcastro92 merged 7 commits intoAug 26, 2026
Conversation
A shared file looked exactly like a regular one. The data to tell them apart arrived with the readdir/stat share flag; nothing rendered it. Adds the badge to both listings — UIItem (desktop, explorer windows, file dialogs) and the dashboard's Files rows — fed from is_shared, and keeps it in step with the share dialogs: both funnel every grant, mode change and revoke through one render, so the badge follows without waiting for a re-listing. Inherited access is deliberately not badged. It is a state of the folder that was shared, so marking every file inside would repeat one fact on hundreds of items; the backend flag is direct-only for the same reason. The icon (owner-shared.svg) and the strings (item_shared_by_you, in 40 locales) were already in the tree, unused — only the wiring was missing. The blue ring is doing the work: list view shrinks badges to 8px, where a glyph is illegible and the white circle the sibling badges use disappears into the row.
Collaborator
Author
Validated in a running local PuterPlaywright against
Tooltip resolves to "You have shared this item with at least one other user." ( Screenshots
GUI suite: 351 passing, including 5 new cases for Not verifiedThe live update path — sharing from the dialog and watching the badge appear without a re-listing. It is a one-liner in each dialog's single Deliberate omissionInherited access is not badged. It is a state of the folder that was shared, so marking every file inside would repeat one fact across hundreds of rows — the backend flag is direct-only for the same reason. |
jfcastro92
changed the title
jfcastro92
changed the title
jfcastro92
changed the title
Review feedback: too big, and in the wrong place. It sat in the badge cluster, which the dashboard pins to the row's top-left corner rather than to the icon — and at 12px it dominated a 24px row icon. Now a dot on the icon itself, lower-right: 9px on the desktop's 45px icons, 7px on the dashboard's 24px rows. Anchoring to .item-icon rather than to the badge cluster is what keeps it on the corner at both sizes. Dropping the people glyph with it — unreadable at either size, and colour was the signal the ticket asked for.
It sat on the icon box's corner, which is 5px outside the artwork on every side, so the dot read as clipped — half of it hanging over empty padding with the icon's own drop-shadow falling across it. Nudged in on both axes: 7px on the desktop, 2px on the dashboard rows.
A recipient given "can edit & share" could not pass that level on: the dialog offered it, the server refused it, and the refusal was a bare 403 Forbidden that reads as a bug. Handing out manage needs authority over manage, which only the owner has — the refusal is right, the dead end and the silence were not. The dropdown now withholds it from anyone who does not own the item; a row already set to it keeps it, so opening the dialog cannot downgrade the owner's own grant, and a mixed selection follows its strictest item. The server says why, and only to someone who can already share the item — a stranger still gets the ACL's own safe error, which does not admit the node exists. Verified against a running server: a delegate grants read and write as before, and manage now answers cannot_delegate_manage with a sentence naming the owner as the one who can.
Sharing a file with someone who already had it answered "Shared with X", the same as a first share, so the dialog claimed to have done something it had not. The service already knew — it computes isNew to decide whether to notify the recipient — but the flag stopped at the controller. It now travels on share results only; a listing describes standing access and says nothing about it. Which of the three things happened is settled client-side, since the mode each recipient holds is already on screen: created access, raised or lowered it, or changed nothing. That keeps the previous mode off the wire, and an older backend that omits isNew still reads as a share, which is what these dialogs said before.
Salazareo
approved these changes
Aug 26, 2026
…-dialog-correctness 🐛 PUT-1586 + PUT-1599: Share dialog says what it can grant, and what it did
…n-readdir-shared-users-in-stat' into juancastro/put-1590-sharing-shared-files-are-not-different-than-regular-files # Conflicts: # src/gui/src/UI/Dashboard/UIShareModal.js # src/gui/src/UI/UIWindowShare.js
Contributor
Coverage Report for puter.js SDK
File Coverage
|
||||||||||||||||||||||||||||||||||||||
Contributor
Coverage Report
File Coverage
|
||||||||||||||||||||||||||||||||||||||||||||
jfcastro92
merged commit Aug 26, 2026
7bd6a2d
into
juancastro/put-1585-share-flag-in-readdir-shared-users-in-stat
11 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #3644 (PUT-1585), which is where
is_sharedcomes from. Base branch is that one, notmain.What this does
A shared file looked exactly like a regular one. The data to tell them apart arrived with the readdir/stat share flag; nothing rendered it.
A blue dot on the item's icon, lower-right, in both listings:
UI/UIItem.js.item-icon— desktop, explorer windows, file dialogsUI/Dashboard/TabFiles.jshelpers/sharedBadge.js(new)has_direct_share(shares)+mark_item_shared(path, on)UI/UIWindowShare.js,UI/Dashboard/UIShareModal.jsrender(), so a grant or revoke updates it without waiting for a re-listinghelpers/refresh_item_container.js,helpers/apply_item_added_to_containers.jscss/style.css,css/dashboard.cssThe string was already in the tree and unused —
item_shared_by_you("You have shared this item with at least one other user"), present in 40 locales. No new i18n key.Design notes
.item-badgesis pinned to the row's top-left in the dashboard, not to the icon, so a badge there could never sit on the file. Anchoring to.item-iconkeeps the marker on the corner at both icon sizes.Validated in a running local Puter
Playwright against
npm start: one shared and one plain item of each kind, badge state read from the rendered DOM. Nothing clicked between the share and the read.data-is_shared10100Captured in both surfaces — the dashboard's Files list and the classic desktop's icon view. GUI suite: 351 passing, including 5 new cases for
has_direct_share(direct, inherited-only, mixed, unclaimed invite, empty).Worth knowing before testing this on a deployment
The GUI loads puter.js from the CDN (
https://js.puter.com/v2/), not from a local build, so the marker stays hidden until #3644's SDK change is published —is_sharedarrives asnulluntil then. The backend wire is already correct (/fs/readdirreturnsisShared: true); it is purely the SDK in the page being the published one. The test routes that URL tosrc/puter-js/dist/puter.dev.js, the way the repo's own browser runner does.Not verified
The live update when sharing from a dialog — the marker appearing without a re-listing. It is a one-liner in each dialog's single
render()funnel andhas_direct_shareis unit-tested, but I did not drive the dialog through the UI.