feat(nav): account-centric dropdown menu

[alukach]

What

Redesigns the nav + account dropdown to make it simple to:

1. Navigate to the Products list view
2. See all orgs that you're a member of ([Proposed Feature] UX - Clearer "My Organizations" List #232)
3. Quickly link to an org's profile page
4. See all products that belong to your orgs
5. Quickly navigate to one of your orgs' products' pages
6. Create new product
7. Create new organization
8. View outstanding invitations
9. Quickly navigate to Admin pages
10. Logout

This generally boils down to a UI like this:

[img] Anthony Lukach  you  ▸ | # <- submenu, your account
[img] NOAA                 ▸ | # <- submenu, any other account you're a member of
──────────────────────────── |
+ New product                | # <- link, if permissions allow
+ New organization           | # <- link, if permissions allow
──────────────────────────── |
Invitations(•)             ▸ | # <- submenu, outstanding membership invitations
Admin                      ▸ | # <- submenu, if permissions allow
──────────────────────────── |
Log out                      |

Before	After

How

• Nav (Navigation → AuthButtons): AuthButtons (server) owns the right
  side and switches responsively — desktop shows the Products link + the account
  dropdown; mobile collapses to a single hamburger. The Products link
  (ProductsNavLink, Berkeley Mono) is shown to everyone but hidden on the
  marketing homepage.
• Data (AuthButtons): resolves what the client can't (memberships only
  carry ids): the org accounts you belong to, the products owned by you and by
  each of those orgs (listByAccount(id, 20), filtered by GetRepository so
  restricted products you can't access aren't shown), and any pending
  invitations — all concurrently. Only org-level memberships (repository_id
  undefined) count as orgs you belong to.
• Desktop dropdown (AccountDropdown): built from DropdownSubmenu, which
  shares a DropdownItems renderer with DropdownSection (items, then
  optional actions after a separator; hidden when empty).
• Mobile (MobileMenu): a full-screen sheet (Radix Themes Dialog) with
  inline single-open accordions and full-width tap targets — same content as the
  dropdown.

Notes / follow-ups

• Product creation is a single "New product" link; the create form already lets
  you pick the owner account.
• The mobile menu is a full-screen sheet with accordion sections; desktop keeps
  the hover dropdown.
• Not visually verified yet (needs a running app + login) — worth a pass on the
  mobile sheet in particular.
• DropdownSection.integration.test.tsx fails locally with React.Children.only
  — pre-existing/environmental (react-slot duplication, as that test documents);
  it fails identically on main and is unrelated to this change.

Tests

• Unit tests for DropdownSection, DropdownSubmenu (visibility + separator
  logic) and accountMenu (invitationLink routing + fallbacks).
• tsc and ESLint clean; 15/15 unit tests pass. (The nav/mobile components are
  UI-only, covered by manual review rather than unit tests.)

🤖 Generated with Claude Code

closes #232
closes #309

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
source-cooperative	Ready	Preview, Comment	Jul 1, 2026 11:37pm

[claude]

Claude finished @alukach's task in 4m 39s —— View job

---

Claude is reviewing this PR

• Gather context (diff, CLAUDE.md, changed files)
• Review changed files for correctness/security/best-practice issues
• Post findings

❌ Changes requested — see findings below.

• src/components/layout/AuthButtons.tsx:52-53 + :72-75 — products are fetched with a hard listByAccount(id, 20) limit before the GetRepository authorization filter is applied, instead of filtering first and then capping. If an org/account has 20+ products and some of the first 20 (in DynamoDB sort-key order) are restricted from the current viewer, the dropdown can show "No products yet" (or a truncated list) even though the viewer actually has access to other products belonging to that account beyond the unfiltered top-20 window. Compare with IndividualProfilePage.tsx:23-31, which fetches up to 1000 products and then filters by Actions.GetRepository — the pattern this PR's comment says it mirrors, but the order of operations doesn't actually match.

  // instead of listByAccount(id, 20) -> filter, over-fetch then filter+cap:
  productsTable.listByAccount(id, 100).then((r) =>
    r.products.filter((p) => isAuthorized(session, p, Actions.GetRepository)).slice(0, 20)
  )

  (Tune the raw limit to whatever's an acceptable worst case for accounts with many restricted products; a full fix would paginate until 20 authorized results are found or the account is exhausted.)

Everything else looks solid:

• newProductUrl(owner) allowlist-checks owner against potentialOwnerAccounts before use (products/new/page.tsx:75-77) — no open redirect / unvalidated owner injection.
• logout() extraction to logout.ts is a faithful, behavior-preserving move from the old inline handleLogout.
• DropdownItems/DropdownSubmenu visibility, separator, and disabled+tooltip logic checked against their new unit tests — matches intent (stable keys via index-then-filter, separator only when both items and actions are non-empty).
• The per-org "New product" permission check (isAuthorized(session, "*", Actions.CreateRepository)) is a coarse, account-agnostic gate — same pattern already used by the standalone /products/new page and enforced precisely (per target org, via hasRole for Owners/Maintainers) server-side in createProduct. Pre-existing pattern, not a regression.

Not evaluated: visual/UX behavior (dropdown/mobile sheet appearance), since this is a static diff review — @tylere's UI feedback in the thread is worth addressing separately but isn't a correctness/security bug.

[tylere]

Notes from experimenting with the UI:

• I would like to see some better indication that the text lines under "View profile" or "View organization" are projects. (Even though I created them, it wasn't immediately clear that they are projects!).
• The "View organization" label has a verb indicating what the link will do, while the product name links do not. Maybe the load web page icon should be used?
• I think it is strange to have a submenu that lists the products of an organization (or user), but have the + New product not in the submenu as well. I think the + New product link should be at the bottom of the list of current projects of the user or organization. This would result in the + New organization link occurring under the list of organizations that the user belongs to (if any), which makes sense to me.
• The user lookup page has a description "Looks up the email in Ory and ...". Suggest removing "in Ory" as an implementation detail (unless Ory is described elsewhere and we want to link to it).
• Logging out took me back to the home page. I didn't expect this, since viewing the user page that I was on doesn't require being logged in. (I realize this might be old behavior because of the branching parent.)

[alukach]

Maybe the load web page icon should be used?

@tylere can you clarify what you mean by the "load web page icon"?

[tylere]

By "load web page icon" I mean't the icon that you pointed out during today's Source Sync. (iirc, this was in response to Michelle's comment about how some links modify the page and some open new pages)