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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		May 21, 2026 10:03am

PR Summary

Low Risk
Low risk UI permission-gating change that only affects whether the Delete action is shown/enabled in the sidebar context menu; no backend or data model changes.

Overview
Fixes the sidebar workflow/folder context menu so Delete is only shown to admins by passing showDelete={userPermissions.canAdmin} from workflow-item and folder-item into ContextMenu.

Simplifies disableDelete in both callers to only consider selection/lock state (since permission gating is now handled via showDelete), preventing non-admin users from seeing a Delete option that would 403.

^{Reviewed by Cursor Bugbot for commit a0bd149. Bugbot is set up for automated code reviews on this repo. Configure here.}

Greptile Summary

This PR fixes a UX/permission mismatch where Write and Read workspace members could see a Delete option in the workflow/folder context menus, even though the DELETE API enforces admin-only access and returns 403 for non-admins. The fix passes showDelete={userPermissions.canAdmin} to the ContextMenu component from both workflow-item and folder-item, hiding the option entirely for non-admin roles.

• workflow-item.tsx and folder-item.tsx: Add showDelete={userPermissions.canAdmin} and simplify disableDelete to only check operational constraints (canDeleteSelection, effectiveLocked), since permission gating is now delegated to showDelete.
• The ContextMenu component already supported showDelete with a default of true; these two call sites simply weren't passing it.

Confidence Score: 5/5

Safe to merge — the change correctly hides a destructive action from users who cannot perform it, and the existing API-level enforcement remains intact as a backstop.

Both changed call sites are symmetric and consistent with how other show* props are already used in the same component. The disableDelete simplification is correct because admins (the only users who now see the button) always have edit permission, so removing !userPermissions.canEdit from that check has no practical effect. The canDeleteSelection and effectiveLocked guards remain, preserving the last-workflow and lock protections.

No files require special attention.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[User right-clicks workflow/folder] --> B{userPermissions.canAdmin?}
    B -- No --> C[showDelete = false\nDelete option hidden]
    B -- Yes --> D[showDelete = true\nDelete option visible]
    D --> E{disableDelete?\neffectiveLocked OR !canDeleteSelection}
    E -- Yes --> F[Delete option shown but disabled]
    E -- No --> G[Delete option shown and enabled]
    G --> H[User clicks Delete]
    H --> I[DELETE API called\naction: 'admin' enforced]
    I --> J[200 OK — item deleted]

_{Reviews (1): Last reviewed commit: "fix(sidebar): pass showDelete to hide de..." | Re-trigger Greptile}

Closing - will reopen against staging branch per contribution guidelines.