wacrm/src/components
Arnas Donauskas 14cdbf457b
feat(ui): role-aware gating sweep + account-name in sidebar
PR 9 of the multi-user accounts series — the final piece. Visual
polish so non-owners see consistent disabled states across the
app and so every user always knows which account they're acting in.

Sidebar
- New account-name strip above the user dropdown, gated behind
  the `account_sharing` beta flag (same flag the Members tab
  from PR 6 reads). For solo users (the default) the account is
  named after them, so showing it would just duplicate the user
  name below — flag-gating keeps the original layout untouched
  for single-user installs.
- When the caller's role is admin/agent/viewer (not owner), the
  role is surfaced as a small uppercase chip alongside the
  account name so they have an unambiguous signal of their
  permission level without opening Settings.
- Nav items stay always-visible per the planning doc's
  "show-but-disable" decision — hiding nav rows by role would
  make the app feel broken.

Inbox composer
- Send button + Templates button + textarea are disabled for
  viewers with a "Read-only — viewers can browse but not reply"
  placeholder and tooltip. The existing session-expired branch
  still wins when it applies (session-expired is the more
  specific condition and surfaces template-only sending).

List-page create buttons
- broadcasts/page.tsx: "New Broadcast" CTA (header + empty
  state).
- automations/page.tsx: "Create Automation" CTA.
- flows/page.tsx: "New flow" CTA (header + empty-state).
- contacts/page.tsx: "Add Contact" + "Import" CTAs.
- pipelines/page.tsx: "Add Pipeline" (gates on edit-settings —
  pipelines are settings-class under the 017 RLS) and "Add
  Deal" (gates on send-messages).

All use `useCan(...)` from PR 5. Disabled buttons get a tooltip
explaining why (`title="Read-only — your role can't ..."`).
Solo users see no visual change — single-owner accounts pass
every capability check.

Why show-but-disable, not hide
- A viewer scanning the app should still see what's possible
  in the product, both to understand what they can ask for an
  upgrade for and to avoid the UI feeling silently broken
  ("the New button just disappeared?"). The tooltip carries
  the explanation cheaply.

Verification
- `npm run lint`      → 0 errors (same 19 pre-existing warnings)
- `npm run typecheck` → clean
- `npm test`          → 366/366 pass
- `npm run build`     → succeeds

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-31 19:02:14 +03:00
..
auth feat(auth): extend useAuth with account context + RequireRole + useCan 2026-05-31 17:58:53 +03:00
automations feat(theme): sweep remaining violet-* → primary across all surfaces 2026-05-22 17:00:32 +03:00
broadcasts chore(templates): polish pass from senior backend / FE / UX review 2026-05-29 17:50:11 +02:00
contacts feat(theme): sweep remaining violet-* → primary across all surfaces 2026-05-22 17:00:32 +03:00
dashboard feat(dashboard): adopt Tremor for charts — first integration 2026-05-31 14:42:10 +03:00
flows feat(flows): canvas / mind-map view (PR 3 of 3 — polish) 2026-05-29 21:04:20 +02:00
inbox feat(ui): role-aware gating sweep + account-name in sidebar 2026-05-31 19:02:14 +03:00
layout feat(ui): role-aware gating sweep + account-name in sidebar 2026-05-31 19:02:14 +03:00
pipelines feat(theme): sweep remaining violet-* → primary across all surfaces 2026-05-22 17:00:32 +03:00
settings feat(settings): members tab + invite member dialog 2026-05-31 18:21:30 +03:00
tremor feat(dashboard): adopt Tremor for charts — first integration 2026-05-31 14:42:10 +03:00
ui feat(theme): sweep remaining violet-* → primary across all surfaces 2026-05-22 17:00:32 +03:00