Fix drop action auth gating

[prxt6529]

Summary by CodeRabbit

• Tests

  • Updated authentication state mock setup in component test suites.

• Refactor

  • Updated authentication state handling for drop action menus.
  • Guest users now display copy-link action only.
  • Authenticated users display the full action menu (quick react, add reaction, reply, boost, and more).

[coderabbitai]

📝 Walkthrough

Walkthrough

This pull request updates authentication state management in wave drop components by migrating from useSeizeConnectContext() to useAuth(). Guest users are now identified by the absence of a connected profile handle, replacing the previous isConnected boolean flag. Both source components and their corresponding tests are updated consistently.

Changes

Cohort / File(s)	Summary
Test Files - Wave Drop Components __tests__/components/waves/drops/WaveDropActions.test.tsx, __tests__/components/waves/drops/WaveDropMobileMenu.test.tsx	Updated mocks to use useAuth hook instead of useSeizeConnectContext. Guest/unauthenticated state now simulated via connectedProfile: null instead of isConnected: false. Assertions updated to reflect new auth state model.
Source Files - Wave Drop Components components/waves/drops/WaveDropActions.tsx, components/waves/drops/WaveDropMobileMenu.tsx	Replaced useSeizeConnectContext() with useAuth() for authentication checks. Introduced showGuestCopyOnly = !connectedProfile?.handle to identify unauthenticated users. Guest users now render copy-link-only UI; authenticated users render full action menus.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• #2233 — Directly modifies the same WaveDropActions and WaveDropMobileMenu components to gate action/menu rendering on authentication state using useSeizeConnectContext().isConnected.
• #1710 — Adds a WaveDropMobileMenuBoost component to WaveDropMobileMenu.tsx, modifying the same file.
• #1715 — Related authentication refactoring that removes AuthContext/connectedProfile usage from WaveDrop components.

Suggested reviewers

• ragnep

Poem

🐰 Hoppy refactoring, the auth flows clean,
From isConnected to handles we've seen,
Guest and authenticated, clear as can be,
Wave drops now know who's logged in to thee! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Fix drop action auth gating' directly and clearly describes the main change: migrating authentication state management from useSeizeConnectContext() to useAuth() and updating guest access control across drop action components.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix-drop-actions-auth-gating

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

__tests__/components/waves/drops/WaveDropMobileMenu.test.tsx (1)

281-318: Add an explicit test for connectedProfile: { handle: null }.

The new tests cover “has handle” and “no profile,” but not the distinct nullable-handle connected state. A focused case here would prevent future auth-gating regressions.

Also applies to: 320-360

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@__tests__/components/waves/drops/WaveDropMobileMenu.test.tsx` around lines
281 - 318, Add a new test case in WaveDropMobileMenu.test.tsx that supplies
AuthContext with connectedProfile: { handle: null } (keep activeProfileProxy
null) and renders WaveDropMobileMenu with the same drop fixture and props
(isOpen, showReplyAndQuote, longPressTriggered, setOpen, onReply, onAddReaction)
to assert the menu behaves like the "no profile" case: owner-only actions (e.g.,
delete, boost, open — the items checked by getByTestId("delete"),
getByTestId("boost"), getByTestId("open")) are not in the document while public
actions like "Copy link" and reaction controls are present; place this alongside
the existing has-handle and no-profile tests to cover the nullable handle state.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@components/waves/drops/WaveDropActions.tsx`:
- Line 39: The current auth gate uses showGuestCopyOnly =
!connectedProfile?.handle which treats connected users without
ApiIdentity.handle as guests; decide the intended rule and implement it: if any
connected user (connectedProfile) should have access, change the condition to
check existence of connectedProfile instead of connectedProfile?.handle (update
usages in WaveDropActions showGuestCopyOnly and related checks around the action
gating); if only handle-bearing users should interact, add an explicit comment
above showGuestCopyOnly documenting that ApiIdentity.handle is required and add
unit/behavioral tests covering a connectedProfile with null handle to ensure the
gating blocks actions; also review and apply the same change or comment/tests to
the analogous checks in WaveDropMobileMenu.

---

Nitpick comments:
In `@__tests__/components/waves/drops/WaveDropMobileMenu.test.tsx`:
- Around line 281-318: Add a new test case in WaveDropMobileMenu.test.tsx that
supplies AuthContext with connectedProfile: { handle: null } (keep
activeProfileProxy null) and renders WaveDropMobileMenu with the same drop
fixture and props (isOpen, showReplyAndQuote, longPressTriggered, setOpen,
onReply, onAddReaction) to assert the menu behaves like the "no profile" case:
owner-only actions (e.g., delete, boost, open — the items checked by
getByTestId("delete"), getByTestId("boost"), getByTestId("open")) are not in the
document while public actions like "Copy link" and reaction controls are
present; place this alongside the existing has-handle and no-profile tests to
cover the nullable handle state.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 478b771c-818f-43a2-9163-e38f0f89b12d

📥 Commits

Reviewing files that changed from the base of the PR and between 444f5c8 and 8bd5e5f.

📒 Files selected for processing (4)

• __tests__/components/waves/drops/WaveDropActions.test.tsx
• __tests__/components/waves/drops/WaveDropMobileMenu.test.tsx
• components/waves/drops/WaveDropActions.tsx
• components/waves/drops/WaveDropMobileMenu.tsx