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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		May 22, 2026 1:39am

PR Summary

Medium Risk
Changes role assignment logic for credential_member on workspace-scoped credentials, which can affect who can edit/delete secrets. Risk is moderate because it alters authorization-relevant data based on workspace permissions rows.

Overview
Workspace-scoped credential creation and env-key sync now consult the workspace permissions table so users with workspace admin permission are recorded as credential_member.role = admin (owner stays admin; write/read remain member).

This removes the shared getWorkspaceMemberUserIds helper and updates ensureWorkspaceCredentialMemberships / bulk membership inserts to compute per-user roles from permissionType, ensuring roles are corrected both when creating new secrets and when syncing existing workspace env credentials.

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

Greptile Summary

This PR fixes workspace admin users being incorrectly assigned member role on credential_member when workspace-scoped secrets were created or synced. It adds a permissions table lookup in ensureWorkspaceCredentialMemberships and in the POST route handler so that workspace admins receive admin credential role.

• environment.ts: ensureWorkspaceCredentialMemberships now accepts workspaceId, queries workspace permissions, and promotes users with admin workspace permission to admin credential role; the call site in syncWorkspaceEnvCredentials is updated accordingly.
• route.ts POST: A parallel permissions query is added alongside the existing member-ID fetch, and the same owner-or-admin check drives the role assigned to each credential_member row.
• createWorkspaceEnvCredentials (also in environment.ts) is a third membership-insertion path that was not updated and still uses the old owner-only admin check, leaving workspace admins with member role when credentials are created through that function.

Confidence Score: 3/5

The fix is correct on the two paths it touches but leaves a third membership-insertion path (createWorkspaceEnvCredentials) using the old logic, so workspace admins will still get the wrong role on credentials created through that function.

Two of the three places that write credential_member rows for workspace-scoped credentials are corrected. createWorkspaceEnvCredentials in environment.ts — which bulk-inserts memberships for newly added env keys — was not updated and still only grants admin to the workspace owner, leaving workspace admins incorrectly assigned member through that code path.

apps/sim/lib/credentials/environment.ts — the createWorkspaceEnvCredentials function (lines 272–285) needs the same permissions-table lookup applied to the other two paths.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Workspace credential created or synced] --> B{Type: env_workspace or service_account?}
    B -- No --> C[Insert single credentialMember as admin for creator]
    B -- Yes --> D[Fetch workspace member IDs + workspace permissions]
    D --> E[For each member user]
    E --> F{Is owner OR creator OR wsPermission === 'admin'?}
    F -- Yes --> G[role = 'admin']
    F -- No --> H[role = 'member']
    G --> I[Insert/Update credentialMember row]
    H --> I

    subgraph "createWorkspaceEnvCredentials (NOT updated)"
        J[Fetch workspace member IDs ONLY] --> K[For each member user]
        K --> L{Is owner?}
        L -- Yes --> M[role = 'admin']
        L -- No --> N[role = 'member — workspace admins get wrong role']
    end

_{Reviews (1): Last reviewed commit: "fix(credentials): reflect workspace perm..." | Re-trigger Greptile}