PipelineCanvas.tsxfeat: pipeline rows select without opening; always-blue task buttons
- Conversation rows select on click; open only via the header column or
double-click. Root fix in useRouteChatThread: on list routes (mail/pipeline)
activeConversationId is an ambient highlight, not intent-to-open, so selecting
a row no longer flips isConversationOpen and swaps the list for the detail view.
- Due tasks always render the blue action button (no plain-text variant); the
"N tasks" summary is a blue button that selects and expands into one blue
button per followup, each linked to its output. "You're caught up" empty state.
- Selected rows expand text fields (next steps, custom fields) to line-clamp-5.
- Pipeline tabs: colour dot is a static indicator (not a picker); drop the Table
create option and the Agenda tab template.
Co-Authored-By: Claude Opus 4.8 (1M context) <<email>>Jul 24, 2026, 10:53 PMPipelineView.tsxfeat(canvas): remove sharing — canvases are single-owner
Two mechanisms are gone:
Per-person grants (canvas_access + shareCanvas/revokeAccess/claimEmailShares).
The procedures existed but nothing in the UI ever called them, so the table never
held a row.
Org-level visibility ('org'/'managers' + getTeamCanvases). The panel behind it was
never rendered either, but this one was reachable: 9 "Org Pipeline" canvases were
marked 'managers' and two users had opened a colleague's.
Access is now ownership. assertCanvasAccess drops from three branches to one, and
getCanvases from a DISTINCT ON over three visibility paths with two LEFT JOINs to a
plain owner-scoped select. canvas_user_settings goes too — it only ever stored a
HomeView position for a canvas someone else owned.
An "Org Pipeline" canvas is still org-WIDE in the data it spans
(view_config.ownerUserIds = 'all_org'); what changes is that each person reads their
own copy. The two users who could see a colleague's canvas but owned no copy —
<email> and <email> — were given one before this landed,
while `visibility` could still identify which canvases were team-visible.
MIGRATION IS DEPLOY-ORDERED. drop_canvas_sharing.sql must run AFTER this deploys:
the currently-running code selects and inserts canvases.visibility, so dropping the
column first breaks canvas listing and creation for everyone.
Co-Authored-By: Claude Opus 5 (1M context) <<email>>Aug 9, 2026, 4:54 PM