@serhiizghama is attempting to deploy a commit to the Sim Team on Vercel.

A member of the Team first needs to authorize it.

PR Summary

Medium Risk
Changes who receives admin on credential_member for workspace secrets, which gates secret edit/delete; scope is small and aligned with workspace admin permissions, but existing memberships may stay wrong until re-synced.

Overview
Fixes a permissions bug where workspace admins (users with workspace admin in permissions, not only the owner) were assigned member on credential_member when workspace secrets were created or synced, blocking edit/delete despite workspace admin access.

Adds getWorkspaceAdminUserIds, which returns the owner plus all workspace permissionType = 'admin' users, and uses that set everywhere credential_member roles are assigned: the credentials POST handler for env_workspace / service_account, ensureWorkspaceCredentialMemberships, syncWorkspaceEnvCredentials, and createWorkspaceEnvCredentials. The creator still gets admin via an explicit check alongside the admin set.

Existing rows are not backfilled by this change; only new creates and env sync paths that run membership ensure get the corrected roles.

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

Greptile Summary

This PR fixes workspace admin users receiving a member role on credential_member records instead of the expected admin role when workspace-scoped secrets are created. It introduces a getWorkspaceAdminUserIds helper that returns the workspace owner plus all users with permissionType = 'admin' in the permissions table, and threads this set through all four affected code paths.

• getWorkspaceAdminUserIds — new exported helper in environment.ts; queries workspace and permissions in parallel, returns a Set<string> used for role determination.
• ensureWorkspaceCredentialMemberships / syncWorkspaceEnvCredentials / createWorkspaceEnvCredentials — now accept/fetch adminUserIds and use adminUserIds.has(memberUserId) instead of the previous owner-only equality check.
• POST /api/credentials — fetches adminUserIds alongside workspaceMemberUserIds and preserves the creator-always-gets-admin fallback (|| memberUserId === session.user.id).

Confidence Score: 4/5

Safe to merge; the fix correctly identifies all affected insertion paths and the admin-set construction is sound. The only concerns are extra DB round-trips and a now-misleading parameter name in the internal helper.

The core logic is correct across all four code paths. Both syncWorkspaceEnvCredentials and createWorkspaceEnvCredentials now issue three workspace-table queries and two permissions queries per call where one of each would suffice — that's a present inefficiency introduced by this PR, not a future risk. No data-correctness bugs or auth regressions were found.

apps/sim/lib/credentials/environment.ts — redundant DB queries in the two bulk-credential functions and the misleading ownerUserId parameter name in the private helper.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant Client
    participant POST as POST /api/credentials
    participant ENV as environment.ts helpers
    participant DB as Database

    Client->>POST: "POST {type: env_workspace/service_account}"
    POST->>DB: BEGIN TRANSACTION
    POST->>DB: INSERT credential
    POST->>ENV: getWorkspaceMemberUserIds(workspaceId)
    ENV->>DB: SELECT workspace (ownerId)
    ENV->>DB: SELECT permissions (all members)
    ENV-->>POST: memberUserIds[]
    POST->>ENV: getWorkspaceAdminUserIds(workspaceId)
    ENV->>DB: SELECT workspace (ownerId) ← duplicate query
    ENV->>DB: "SELECT permissions WHERE permissionType='admin'"
    ENV-->>POST: adminIds (Set)
    loop each memberUserId
        POST->>DB: "INSERT credentialMember (role = adminIds.has(uid) OR uid==creator ? admin : member)"
    end
    POST->>DB: COMMIT
    POST-->>Client: 200 OK

_{Reviews (1): Last reviewed commit: "fix(credentials): apply admin role check..." | Re-trigger Greptile}