feat(database,web): automation access by scope: personal vs workspace (D2)
PR 1b of the approved automations plan (docs/proposals/automations-scope.md Ā§4 and D2). Stacked on #2616.
Who may do what (AUTOMATION_ACCESS in the store, one rule each):
| Personal | Workspace | |
|---|---|---|
| Read (list, detail, runs) | its creator; owners and admins | every member |
| Change | its creator | its creator, owners, and admins |
| Turn on or off | its creator; owners and admins | every member |
| Run now | its creator | every member |
| Delete | its creator; owners and admins | its creator, owners, and admins |
- Membership comes first. Every rule requires the account to still be a member of the automation's workspace, so a creator who left reaches nothing of theirs, while the workspace's owners and admins go on seeing and deleting it (D6). A row an older build wrote with no workspace yet is its plan's workspace's.
- Runs still run as the creator, on the creator's keys (D3), whoever presses Run now. A run whose creator left the workspace fails as the new reason
creator-leftand starts nothing, and the next firing tries again. The sweep claims a departed creator's schedule so that its failure shows, rather than skipping it silently (D6). - Roles: an owner or admin named among several roles in the plugin's role text (e.g.
member,admin) is matched, asroleOfreads it. - A plan moved into a personal workspace turns its workspace automations personal.
- Refusals:
- A PATCH that only sets
enabledis the toggle; anything else needs Change. - An automation the account can read but may not change, run or delete is refused as
not-permitted(403). - One it cannot read stays
not-found.
- A PATCH that only sets
- Test support:
WORKSPACE_ROLEnow comes from the wire (owner, admin, member). It used to be a local copy without admin.
Test (automations-app.test.ts, fails on #2616's owner-only rule): a creator, a member and an admin in one workspace.
- The member lists the workspace automation but not the creator's personal one, and the admin lists every automation.
- The member renames (403), pauses (200), runs (201) and deletes (403) the workspace one, and can't run the personal one (404).
- The admin renames the workspace one (200), and pauses (200) but neither renames (403) nor runs (403) the personal one.
- After the member leaves, they list nothing, and the admin deletes their automation.
No Mac UI. pnpm check:affected exits 0.
š¤ Generated with Claude Code
Summary by cubic
Implements the D2 automation access rules (docs/proposals/automations-scope.md): personal automations are their creator's (owners and admins see, pause, and delete, but only the creator changes and runs), while workspace automations are seen, run, and paused by every member and changed and deleted by their creator, owners, and admins. Every rule requires workspace membership, so a creator who left the workspace reaches nothing of theirs while its owners and admins keep access.
Behavior
- A PATCH that only sets
enabledis the toggle; any other PATCH requires change access. - Operations on an automation the account can read but may not perform fail as
not-permitted(403); unreadable ones staynot-found. - Runs still execute as the creator on the creator's keys; one whose creator left fails as
creator-leftand the next firing tries again. The sweep claims a departed creator's schedule so the failure shows instead of skipping it silently. - A plan moved into a personal workspace turns its workspace automations personal.
- Owners and admins are matched even when named among several roles (e.g.
member,admin). WORKSPACE_ROLEnow comes from the wire, adding theadminrole.