Let clip viewers reshare public/org clips via copy-link

[SajalChaplot]

Summary

• A plain viewer who reached a clip via public/org visibility never saw the Share button on /share/:shareId — it was gated on viewerCanEdit (owner/admin/editor only), even though the dialog's copy-link field already worked for any role once opened.
• Show the Share button to viewers too when recording.visibility is public or org (a viewer on a narrowly-shared private clip still sees nothing, preserving the owner's tighter intent).
• Restrict such a viewer's dialog to the Link + Embed tabs (hide Invite), so they can only forward the clip via copy-link — not invite by email/role, see the full people-with-access list, or change visibility (visibility control was already disabled for non-managers).

Why

Goal: when another user views a clip the creator shared with visibility set to public or organization, the receiver should be able to reshare that clip (to humans or agents) via a simple copy-link, without gaining any admin-level sharing controls.

Viewer UI for public link

Viewer UI for org link

No backend/action changes were needed — list-resource-shares and create-recording-agent-link already permit any viewer; only the Share button's visibility and the dialog's tab set needed adjusting.

Test plan

• oxfmt on both touched files
• Ran the clips dev server locally; confirmed as owner the Share dialog is unchanged (Link/Invite/Embed all present, invite-by-email + role picker work, people list renders)
• Traced the viewer-facing logic against the existing viewerCanEdit/canManage patterns (exact conditions added, no new state)
• Full live check of the viewer path on /share/:shareId was blocked by an unrelated, pre-existing gate in a fresh local dev DB (no storage provider configured → clip never reaches status: "ready", which early-returns before the Share button code for any role) — reviewers with a ready clip and a second account should confirm the Share button now appears for a viewer role on public/org clips and that the dialog shows Link+Embed only.

[github-actions]

Here's a visual recap of what changed:

Open the full interactive recap

[SajalChaplot]

@builderio-bot look at latest PR feedback and fix anything you agree with. Be skeptical. Reply to every comment (directly on the comment thread of each comment) if you fixed it or not and why. then check back every 2 minutes on a loop and see if any new feedback posted, until at least 20 minutes go by without any new feedback posted we want to address, including making sure CI passes too and no merge conflicts (make sure code is mergeable)

[steve8708]

@SajalChaplot can you share a screenshot of the change?

[SajalChaplot]

@steve8708 I couldn't figure out the deploy preview url for clips. What is it named? I can capture the screenshot there.

[steve8708]

are you using Builder or a local dev env? would suggest making sure you do one of those so you aren't dependent on deployment for UI testing

[builder-io-integration]

I encountered an error while processing your request. Please try again.

[SajalChaplot]

Added the screenshot. It is viewer inside organization. Was using local environment with claude, Builder app just keeps crashing my mac. Idk why.

[builder-io-integration]

Builder reviewed your changes and found 1 potential issue 🔴

Review Details

Code Review Summary

This incremental review verifies that the previously reported private-viewer route condition was updated to restrict viewerReshareOnly to public/org recordings. However, the viewer-only flag is not propagated into LinkTab, so the core restriction is incomplete for organization-visible viewers.

Key Findings

🔴 HIGH: An org viewer who opens the newly available Share dialog can still trigger create-recording-agent-link and see the agent-sharing controls. The flag currently only disables the access-list query and Invite tab; LinkTab still treats the initial org visibility as loaded and runs its non-public agent-link effect. This mints a bearer URL beyond the intended copy-link-only capability.

The editor/admin paths and native download gating otherwise remain consistent. Risk classification: High because this concerns sharing authorization and bearer-link creation. Browser testing was attempted, but authentication was blocked by a sandbox-wide Neon/Postgres pool failure; static source analysis confirmed the finding.

🧪 Browser testing: Will run after this review (PR touches UI code).

[builder-io-integration]

🔴 Propagate viewer-only restrictions into LinkTab

viewerReshareOnly prevents the shares query and hides Invite, but it is not passed to LinkTab. For an org-visible viewer, initialVisibility makes the link state loaded, so LinkTab still runs create-recording-agent-link and renders the agent-sharing controls, allowing a bearer URL instead of only the intended human copy link. Pass the restriction through and suppress the agent-link mutation/controls (and other non-copy-only extras) in viewer-only mode.

Additional Info

The LinkTab effect invokes the mutation whenever visibility is non-public; org visibility therefore follows that path even though ShareRecordingContent is in viewerReshareOnly mode.

[builder-io-integration]

Agreed, real gap — viewerReshareOnly only stopped list-resource-shares and the Invite tab, but LinkTab's own effect independently calls create-recording-agent-link whenever !isPublic, which includes org-visibility reshare viewers, minting a scoped bearer-token URL for them.

Fixed in 827f365: threaded viewerReshareOnly down into LinkTab, added it to the effect's early-return guard so the agent link is never minted in that mode, and hid the whole "share with agents" block (!isPublic && !viewerReshareOnly) since there's no bearer-token-minting capability to offer a bare-link-only viewer anyway.

[SajalChaplot]

@builderio-bot look at latest PR feedback and fix anything you agree with. Be skeptical. Reply to every comment (directly on the comment thread of each comment) if you fixed it or not and why. then check back every 2 minutes on a loop and see if any new feedback posted, until at least 20 minutes go by without any new feedback posted we want to address, including making sure CI passes too and no merge conflicts (make sure code is mergeable)

[builder-io-integration]

There was a problem with your request, please try again later. Error id: 0be7ccfce6ac48f7ab58235bbc48cf00

[SajalChaplot]

@builderio-bot look at latest PR feedback and fix anything you agree with. Be skeptical. Reply to every comment (directly on the comment thread of each comment) if you fixed it or not and why. then check back every 2 minutes on a loop and see if any new feedback posted, until at least 20 minutes go by without any new feedback posted we want to address, including making sure CI passes too and no merge conflicts (make sure code is mergeable)

Goal for this PR was to allow non-clip owners within an organization to have an option to share clip to agent.

[builder-io-integration]

20 minutes have passed with no new feedback, all CI checks green, no merge conflicts, mergeStateStatus: CLEAN, and mergeable. Stopping the loop per the stated stop condition.

Summary

Nothing new arrived since I last resolved conflicts — no new review comments to fix, and CI stayed green for the full 20-minute window. I also verified against the stated PR goal ("let non-clip-owners within an org share a clip to an agent"): the current code gates the visibility dropdown and the Invite/People list behind canViewShares (owner/admin/editor only), but the "share with agents" section is only gated by !isPublic, so org viewers and commenters can still generate an agent-share link — the goal is intact. PR #2812 is clean, mergeable, and fully green.

---

⠀
🟢 20-minute quiet window elapsed with no new PR feedback, CI fully green, no conflicts — PR #2812 is mergeable and confirmed to still meet the "non-owner org sharing" goal.