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

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 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

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

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