fix(access-control): exempt legacy blocks

[icecrasher321]

Summary

Exempt legacy blocks from access controls

Type of Change

• Bug fix

Testing

Tested manually

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jun 15, 2026 7:37pm

[cursor]

PR Summary

Medium Risk
Changes enterprise access-control enforcement and broadens bypass beyond start_trigger to all toolbar-hidden blocks; incorrect hideFromToolbar metadata could unintentionally allow integrations.

Overview
Introduces isBlockTypeAccessControlExempt in lib/permission-groups/block-access.ts as the shared rule for block types that skip integration allowlists: start_trigger and any block with hideFromToolbar: true (legacy/deprecated integrations).

Runtime and client enforcement no longer special-case only start_trigger; they call this helper in validateBlockType, assertPermissionsAllowed, usePermissionConfig (isBlockAllowed / filterBlocks), copilot isBlockTypeAllowed, and the Access Control blocks list (exempt types stay out of the admin allowlist UI).

Tests mock getBlock and assert legacy types like notion with hideFromToolbar: true pass allowlist checks even when not on the group list.

^{Reviewed by Cursor Bugbot for commit d7bb037. Configure here.}

[greptile-apps]

Greptile Summary

This PR fixes a regression where legacy blocks (deprecated integrations with hideFromToolbar: true) were silently blocked at runtime because admins had no way to add them to the integration allowlist. A new isBlockTypeAccessControlExempt helper in lib/permission-groups/block-access.ts becomes the single source of truth for which block types bypass access-control checks, replacing scattered inline blockType === 'start_trigger' guards across four call sites.

• New block-access.ts utility — defines two exempt categories: start_trigger (always runnable) and any block where hideFromToolbar: true (legacy/deprecated). This keeps the admin UI display set and the runtime enforcement set permanently in sync.
• Four call sites updated — permission-check.ts (server enforcement), use-permission-config.ts (client filtering), access-control.tsx (admin UI block list), and validation.ts (copilot workflow-edit path) all now delegate to the shared helper.
• Test coverage added — two new cases in permission-check.test.ts verify legacy blocks pass both validateBlockType and assertPermissionsAllowed when the integration allowlist would otherwise block them.

Confidence Score: 5/5

Safe to merge — the change consolidates an existing exemption pattern into a shared helper and extends it to legacy blocks, with no new security surface.

All four enforcement call sites are updated consistently. The new isBlockTypeAccessControlExempt helper is synchronous, delegates to the existing block registry, and is already used client-side safely (the registry was already client-importable). Model and toolKind checks in assertPermissionsAllowed are correctly preserved when a block is exempt. Test coverage covers both the direct validateBlockType path and the unified assertPermissionsAllowed path with a mocked legacy block.

No files require special attention.

Important Files Changed

Filename	Overview
apps/sim/lib/permission-groups/block-access.ts	New single source of truth for access-control exemption: exempts start_trigger and any block with hideFromToolbar: true, with clear docstring explaining the two exemption categories.
apps/sim/ee/access-control/utils/permission-check.ts	Replaces inline blockType === 'start_trigger' guards with isBlockTypeAccessControlExempt; logic for assertPermissionsAllowed correctly preserves model/toolKind checks when a block is exempt.
apps/sim/ee/access-control/utils/permission-check.test.ts	Adds mock for getBlock, a global beforeEach to prevent implementation leakage, and two new test cases covering legacy-block exemption in both validateBlockType and assertPermissionsAllowed.
apps/sim/hooks/use-permission-config.ts	Client-side hook updated to use isBlockTypeAccessControlExempt in both isBlockAllowed and filterBlocks; registry lookup is safe on the client since getAllBlocks was already imported client-side.
apps/sim/ee/access-control/components/access-control.tsx	Admin UI block list now filtered via isBlockTypeAccessControlExempt, keeping the displayed set consistent with the enforcement paths.
apps/sim/lib/copilot/tools/server/workflow/edit-workflow/validation.ts	Copilot workflow-edit validation now checks the shared exemption function before consulting the permission config, consistently extending legacy-block support to the AI edit path.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Block type to check] --> B{isBlockTypeAccessControlExempt?}
    B -->|start_trigger| C[✅ Exempt — return allowed]
    B -->|hideFromToolbar === true| C
    B -->|No| D{Permission config loaded?}
    D -->|No config / allowedIntegrations null| E[✅ Unrestricted — return allowed]
    D -->|Config with allowedIntegrations| F{blockType in allowedIntegrations?}
    F -->|Yes| G[✅ Allowed]
    F -->|No| H[❌ IntegrationNotAllowedError]

    subgraph Call sites
        S1["validateBlockType (server)"]
        S2["assertPermissionsAllowed (server)"]
        S3["isBlockAllowed / filterBlocks (client hook)"]
        S4["isBlockTypeAllowed (copilot validation)"]
    end

    S1 & S2 & S3 & S4 --> A

Loading

_{Reviews (1): Last reviewed commit: "fix(access-control): exempt legacy block..." | Re-trigger Greptile}