fix: make the block list bite on team shares, and unshare every re-share (PUT-1813)

A sender a member blocked could still land items in that member's
shared-with-me — and grant them real access — by sharing with a common
team. The group grant is one row and cannot exclude a member, so the
block is now enforced where delivery is derived per member: the
permission scan, the inbound listing and its count, and the fs-event
fan-out all skip team rows whose issuer the member blocked. Nothing is
revoked, so unblocking restores everything. Blocking now also bumps the
blocker's permission cache so it bites immediately. Direct shares keep
their contract: existing ones stand.

#unshareTeam swept re-shares by listing members with a 200 cap and
never following the cursor, so members past the cap kept their orphaned
rows. It now walks the share rows in the subtree — the set that can
actually need sweeping — and filters those issuers to members, which
has no cap by construction.
This commit is contained in:
Juan Castro
2026-09-15 14:49:54 -04:00
parent f428797a79
commit 9da03555ae
8 changed files with 366 additions and 31 deletions
+2
View File
@@ -35,6 +35,8 @@ Who to share with. A string containing `@` is treated as an email address, and a
Where the deployment has [Teams](/Teams/), pass `{ team: uid }` to share with every member of a team the caller belongs to — including anyone added to it later. There is no string form for a team: a bare string is always read as an email or username.
A team share is never refused for one member's sake, so it does not produce `recipient_not_accepting_shares` — but a member who has blocked the sharer is not reached by it. Nothing you share with the team is listed for them, accessible to them, or announced to them while their block stands; the rest of the team is unaffected, and nothing tells the sharer.
#### `mode` (String) (optional)
How much access to grant. Defaults to `'read'`.
+4
View File
@@ -60,6 +60,10 @@ including anyone added later. Pass the team's `uid` as the recipient:
await puter.fs.share({ path, recipient: { team: team.uid }, mode: 'read' });
```
A member who has blocked the sharer is the one exception: while the block
stands, that member neither sees nor can open anything the sharer put into the
team, and the sharer is not told.
See [`puter.fs.share()`](/FS/share/) for the full sharing API.
## Pagination