fix(I3): carry isOwner on the workspace link so Unlink is not offered-then-refused
Unlinking is owner-only and the server enforces it with a 403, but the link payload carried no ownership signal - so a colleague reading a firm-visible matter saw an Unlink button and only learned it was not theirs by pressing it. toLink already had the authorising `checkProjectAccess` result in hand, so isOwner is derived from that same result and cannot disagree with what the server will enforce. The two write paths (linkWorkspace, createWorkspaceForMatter) pass true by construction - both refuse or create for the caller as owner. The frontend withholds the button rather than disabling it; the handler keeps its 403 branch as the belt for a payload that went stale under an open page. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
| Repository | Sloth-ninja/JessicaOSS |
|---|---|
| Author | sloth-ninja <ezanahaddis@gmail.com> |
| Authored | |
| Parents | a46ca14f |
| Stats | 4 files changed , +85 , -21 |
| Part of | Practice Management: Clio-backed Matters and workspace links |
Capture this commit into my fork
Download a Markdown prompt that tells Claude how to port this
exact commit into your working tree. Run it via
claude -p < capture-commit-a0c89e55.md
from inside the repo you want the change in.