feat(backend): Add Backend API calls for organization perms, roles#8774
Merged
Conversation
…le sets Add Backend API support for managing instance-level organization RBAC. `createClerkClient()` now exposes: - `organizationPermissions` — list, get, create, update, and delete organization permissions. - `organizationRoles` — list, get, create, update, and delete organization roles, plus assign/remove a permission to/from a role. - `roleSets` — list, get, create, update, add roles to, replace a role in, and replace a role set.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: 2554467 The changes in this PR will be included in the next version bump. This PR includes changesets to release 10 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
📝 WalkthroughWalkthroughThis PR adds backend API support for managing instance-level organization RBAC. It introduces resource models for permissions, roles, and role sets; three new endpoint client classes with full CRUD operations; comprehensive test coverage for all endpoints; and factory integration to expose these managers via ChangesOrganization RBAC Backend API Support
🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
Warning Review ran into problems🔥 ProblemsStopped waiting for pipeline failures after 30000ms. One of your pipelines takes longer than our 30000ms fetch window to run, so review may not consider pipeline-failure results for inline comments if any failures occurred after the fetch window. Increase the timeout if you want to wait longer or run a Comment |
Contributor
|
Break Check: no API changes detected across the tracked packages. Last ran on |
@clerk/astro
@clerk/backend
@clerk/chrome-extension
@clerk/clerk-js
@clerk/expo
@clerk/expo-passkeys
@clerk/express
@clerk/fastify
@clerk/hono
@clerk/localizations
@clerk/nextjs
@clerk/nuxt
@clerk/react
@clerk/react-router
@clerk/shared
@clerk/tanstack-react-start
@clerk/testing
@clerk/ui
@clerk/upgrade
@clerk/vue
commit: |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (9)
packages/backend/src/api/endpoints/OrganizationRoleApi.ts (1)
76-136: ⚡ Quick winAdd explicit return types for the public
OrganizationRoleAPImethods.Please annotate all public methods with explicit
Promise<...>return types instead of relying on inference.As per coding guidelines, “Always define explicit return types for functions, especially public APIs.” Based on learnings, this repo expects explicit return types on exported/public TS APIs.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/backend/src/api/endpoints/OrganizationRoleApi.ts` around lines 76 - 136, Add explicit Promise return types to all public methods on OrganizationRoleApi: annotate getOrganizationRoleList, getOrganizationRole, createOrganizationRole, updateOrganizationRole, deleteOrganizationRole, assignPermissionToOrganizationRole, and removePermissionFromOrganizationRole with their proper Promise<T> signatures (e.g., Promise<PaginatedResourceResponse<Role[]>> for getOrganizationRoleList, Promise<Role> for single Role responses, Promise<DeletedObject> for delete). Update the method declarations to return Promise<...> instead of relying on type inference so the public API has explicit return types.Sources: Coding guidelines, Learnings
packages/backend/src/api/endpoints/OrganizationPermissionApi.ts (1)
46-86: ⚡ Quick winAdd explicit return types to all public endpoint methods.
These exported API methods currently depend on inference. Please annotate each public method with its
Promise<...>return type to keep the SDK contract explicit.Suggested patch
export class OrganizationPermissionAPI extends AbstractAPI { - public async getOrganizationPermissionList(params: GetOrganizationPermissionListParams = {}) { + public async getOrganizationPermissionList( + params: GetOrganizationPermissionListParams = {}, + ): Promise<PaginatedResourceResponse<Permission[]>> { @@ - public async getOrganizationPermission(permissionId: string) { + public async getOrganizationPermission(permissionId: string): Promise<Permission> { @@ - public async createOrganizationPermission(params: CreateOrganizationPermissionParams) { + public async createOrganizationPermission(params: CreateOrganizationPermissionParams): Promise<Permission> { @@ - public async updateOrganizationPermission(params: UpdateOrganizationPermissionParams) { + public async updateOrganizationPermission(params: UpdateOrganizationPermissionParams): Promise<Permission> { @@ - public async deleteOrganizationPermission(permissionId: string) { + public async deleteOrganizationPermission(permissionId: string): Promise<DeletedObject> {As per coding guidelines, “Always define explicit return types for functions, especially public APIs.” Based on learnings, explicit return annotations are expected for exported/public TypeScript APIs.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/backend/src/api/endpoints/OrganizationPermissionApi.ts` around lines 46 - 86, Public methods in OrganizationPermissionApi (getOrganizationPermissionList, getOrganizationPermission, createOrganizationPermission, updateOrganizationPermission, deleteOrganizationPermission) lack explicit return type annotations; update each method signature to declare the Promise return type that matches the request generic (e.g., getOrganizationPermissionList(): Promise<PaginatedResourceResponse<Permission[]>>) so the SDK contract is explicit, keeping method bodies unchanged and ensuring types align with the this.request<...> generic used in each implementation.Sources: Coding guidelines, Learnings
packages/backend/src/api/endpoints/RoleSetApi.ts (1)
132-194: ⚡ Quick winAdd explicit return types for the public
RoleSetAPImethods.These public SDK methods should use explicit
Promise<...>return annotations for a stable, explicit API contract.As per coding guidelines, “Always define explicit return types for functions, especially public APIs.” Based on learnings, explicit return typing is required for exported/public TS methods.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/backend/src/api/endpoints/RoleSetApi.ts` around lines 132 - 194, The public RoleSetApi methods lack explicit Promise return types; update each method signature to declare its explicit Promise<...> return type: getRoleSetList should return Promise<PaginatedResourceResponse<RoleSet[]>>, getRoleSet/createRoleSet/updateRoleSet/addRolesToRoleSet/replaceRoleInRoleSet should return Promise<RoleSet>, and replaceRoleSet should return Promise<DeletedObject>; adjust the signatures for getRoleSetList, getRoleSet, createRoleSet, updateRoleSet, addRolesToRoleSet, replaceRoleInRoleSet, and replaceRoleSet to include these explicit Promise return annotations.Sources: Coding guidelines, Learnings
packages/backend/src/api/endpoints/index.ts (1)
21-27: 🏗️ Heavy liftDon’t grow
index.tsbarrels unless explicitly exempted.These additions increase coupling risk in a disallowed pattern; prefer explicit module entry points or document an exception for this file.
As per coding guidelines, "
**/index.ts: Avoid barrel files (index.ts re-exports) as they can cause circular dependencies."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/backend/src/api/endpoints/index.ts` around lines 21 - 27, This index.ts barrel is adding many re-exports (OrganizationPermissionApi, OrganizationRoleApi, OAuthApplicationsApi, PhoneNumberApi, ProxyCheckApi, RedirectUrlApi, RoleSetApi) which violates the no-barrel rule; remove these export lines from index.ts and update consumers to import directly from each module's explicit path (e.g., import from './OrganizationPermissionApi' etc.), or if this file must remain a barrel for a validated reason, add a clear exemption comment at the top of index.ts referencing the exception and ensure reviewers approve it.Source: Coding guidelines
packages/backend/src/api/__tests__/OrganizationRoleApi.test.ts (1)
43-166: ⚡ Quick winExpand role API tests to include validation/error paths.
Please add edge-case tests for invalid IDs and failed backend responses, including assign/remove permission flows.
As per coding guidelines, "
**/*.{test,spec}.{ts,tsx}: ... Verify proper error handling and edge cases."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/backend/src/api/__tests__/OrganizationRoleApi.test.ts` around lines 43 - 166, Add unit tests in OrganizationRoleApi.test.ts to cover error/edge cases: for getOrganizationRole (organizationRoles.getOrganizationRole), updateOrganizationRole (organizationRoles.updateOrganizationRole), deleteOrganizationRole (organizationRoles.deleteOrganizationRole), assignPermissionToOrganizationRole (organizationRoles.assignPermissionToOrganizationRole) and removePermissionFromOrganizationRole (organizationRoles.removePermissionFromOrganizationRole) add cases that assert proper handling when the backend returns 4xx/5xx (mock server returning error responses) and when invalid IDs (e.g., empty string or malformed id) are passed; for createOrganizationRole also add a validation error case. Use server.use with http.<method> for the failing responses and expect the API client to throw or return the appropriate error shape/exception so tests assert that error propagation/validation behavior matches guidelines.Source: Coding guidelines
packages/backend/src/api/__tests__/OrganizationPermissionApi.test.ts (1)
30-127: ⚡ Quick winAdd negative-path coverage for permission endpoints.
Please add tests for error handling/edge cases (e.g., invalid/empty IDs and non-2xx responses) so these methods are covered beyond happy paths.
As per coding guidelines, "
**/*.{test,spec}.{ts,tsx}: Unit tests are required for all new functionality ... Verify proper error handling and edge cases."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/backend/src/api/__tests__/OrganizationPermissionApi.test.ts` around lines 30 - 127, Add negative-path unit tests in packages/backend/src/api/__tests__/OrganizationPermissionApi.test.ts to cover error handling for organizationPermissions methods: getOrganizationPermissionList, getOrganizationPermission, createOrganizationPermission, updateOrganizationPermission, and deleteOrganizationPermission. For each method add cases that simulate non-2xx HTTP responses (e.g., 400/404/500 via server.use with HttpResponse.json or HttpResponse.text and appropriate status) and assertions that the API client throws or returns the expected error shape; also add edge-case tests for invalid/empty IDs (call getOrganizationPermission/updateOrganizationPermission/deleteOrganizationPermission with '' or null and assert validation error or thrown exception) and for create/update with invalid payloads to assert proper error propagation. Ensure each new test mirrors the existing test style (using validateHeaders/http helpers) and asserts on the thrown error or returned error properties so negative flows are covered.Source: Coding guidelines
packages/backend/src/api/factory.ts (1)
46-120: 🏗️ Heavy liftAdd an explicit return type for
createBackendApiClient.This exported public API currently relies on inference; define and annotate a named return type/interface to lock the contract.
As per coding guidelines, "
**/*.{ts,tsx}: Always define explicit return types for functions, especially public APIs."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/backend/src/api/factory.ts` around lines 46 - 120, Add an explicit exported return type for createBackendApiClient: declare and export an interface (e.g. BackendApiClient) that lists the public members returned (use the exact symbols from the factory such as __experimental_accountlessApplications: AccountlessApplicationAPI, actorTokens: ActorTokenAPI, agentTasks: AgentTaskAPI, apiKeys: APIKeysAPI, m2m: M2MTokenApi, samlConnections: SamlConnectionAPI, etc.), then annotate the function signature as createBackendApiClient(options: CreateBackendApiOptions): BackendApiClient. Keep the interface members' types aligned with the existing classes/constructors used in the return object so the public contract is locked and the function no longer relies on type inference.Source: Coding guidelines
packages/backend/src/api/resources/index.ts (1)
52-57: 🏗️ Heavy liftAvoid expanding
index.tsbarrel exports without an explicit exception.These new re-exports add more surface to a barrel file; prefer concrete module exports/imports (or document a scoped exception if this barrel is intentionally allowed).
As per coding guidelines, "
**/index.ts: Avoid barrel files (index.ts re-exports) as they can cause circular dependencies."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/backend/src/api/resources/index.ts` around lines 52 - 57, The index.ts barrel export was expanded to re-export Permission, PhoneNumber, ProxyCheck, RedirectUrl, Role, and RoleSet which violates the "avoid barrel files" guideline; revert those re-exports and instead import the specific modules where needed (or, if this barrel is intentionally allowed, add a documented, scoped exception comment above the exports explaining why these resources must be re-exported). Locate the index.ts barrel (the file that currently exports Permission, PhoneNumber, ProxyCheck, RedirectUrl, Role, RoleSet) and either remove those export lines and use direct imports in callers, or add a clear comment and update project documentation to justify keeping them.Source: Coding guidelines
packages/backend/src/api/__tests__/RoleSetApi.test.ts (1)
67-191: ⚡ Quick winComplete RoleSet coverage for ID variant and failure paths.
The “key or ID” contract should be tested for an ID input too, and this suite should also include error/edge-case assertions (invalid IDs, failed responses).
As per coding guidelines, "
**/*.{test,spec}.{ts,tsx}: Unit tests are required for all new functionality ... Verify proper error handling and edge cases."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/backend/src/api/__tests__/RoleSetApi.test.ts` around lines 67 - 191, Tests currently only exercise roleSets.getRoleSet using the key variant and lack negative/ID-path coverage; add unit tests in RoleSetApi.test.ts that call roleSets.getRoleSet with roleSetId (the numeric/ID variant) and assert the same fields as the key test, plus add tests simulating error responses via server.use (e.g., return 404 and 500 HttpResponse) to assert the client throws or returns the expected error shape, and add an invalid-ID input test (call roleSets.getRoleSet with a malformed id and expect validation/error) so both success-by-ID and failure/edge cases for getRoleSet (and similarly for other methods if desired) are covered; use the existing helpers (server.use, HttpResponse.json, validateHeaders) and reference roleSets.getRoleSet, roleSets.createRoleSet, roleSets.updateRoleSet, roleSets.addRolesToRoleSet, roleSets.replaceRoleInRoleSet, and roleSets.replaceRoleSet to locate where to add these tests.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/backend/src/api/factory.ts`:
- Around line 101-106: Add clear JSDoc comments for the new public client
members organizationPermissions, organizationRoles, and roleSets in the API
factory (the variables OrganizationPermissionAPI, OrganizationRoleAPI,
RoleSetAPI) describing their purpose, public usage surface, and any return types
or important behaviors; ensure the JSDoc style matches existing entries for
phoneNumbers, proxyChecks, and redirectUrls so generated docs remain consistent,
then mark the change for Docs-team review so reference documentation in
clerk/javascript can be updated if necessary.
---
Nitpick comments:
In `@packages/backend/src/api/__tests__/OrganizationPermissionApi.test.ts`:
- Around line 30-127: Add negative-path unit tests in
packages/backend/src/api/__tests__/OrganizationPermissionApi.test.ts to cover
error handling for organizationPermissions methods:
getOrganizationPermissionList, getOrganizationPermission,
createOrganizationPermission, updateOrganizationPermission, and
deleteOrganizationPermission. For each method add cases that simulate non-2xx
HTTP responses (e.g., 400/404/500 via server.use with HttpResponse.json or
HttpResponse.text and appropriate status) and assertions that the API client
throws or returns the expected error shape; also add edge-case tests for
invalid/empty IDs (call
getOrganizationPermission/updateOrganizationPermission/deleteOrganizationPermission
with '' or null and assert validation error or thrown exception) and for
create/update with invalid payloads to assert proper error propagation. Ensure
each new test mirrors the existing test style (using validateHeaders/http
helpers) and asserts on the thrown error or returned error properties so
negative flows are covered.
In `@packages/backend/src/api/__tests__/OrganizationRoleApi.test.ts`:
- Around line 43-166: Add unit tests in OrganizationRoleApi.test.ts to cover
error/edge cases: for getOrganizationRole
(organizationRoles.getOrganizationRole), updateOrganizationRole
(organizationRoles.updateOrganizationRole), deleteOrganizationRole
(organizationRoles.deleteOrganizationRole), assignPermissionToOrganizationRole
(organizationRoles.assignPermissionToOrganizationRole) and
removePermissionFromOrganizationRole
(organizationRoles.removePermissionFromOrganizationRole) add cases that assert
proper handling when the backend returns 4xx/5xx (mock server returning error
responses) and when invalid IDs (e.g., empty string or malformed id) are passed;
for createOrganizationRole also add a validation error case. Use server.use with
http.<method> for the failing responses and expect the API client to throw or
return the appropriate error shape/exception so tests assert that error
propagation/validation behavior matches guidelines.
In `@packages/backend/src/api/__tests__/RoleSetApi.test.ts`:
- Around line 67-191: Tests currently only exercise roleSets.getRoleSet using
the key variant and lack negative/ID-path coverage; add unit tests in
RoleSetApi.test.ts that call roleSets.getRoleSet with roleSetId (the numeric/ID
variant) and assert the same fields as the key test, plus add tests simulating
error responses via server.use (e.g., return 404 and 500 HttpResponse) to assert
the client throws or returns the expected error shape, and add an invalid-ID
input test (call roleSets.getRoleSet with a malformed id and expect
validation/error) so both success-by-ID and failure/edge cases for getRoleSet
(and similarly for other methods if desired) are covered; use the existing
helpers (server.use, HttpResponse.json, validateHeaders) and reference
roleSets.getRoleSet, roleSets.createRoleSet, roleSets.updateRoleSet,
roleSets.addRolesToRoleSet, roleSets.replaceRoleInRoleSet, and
roleSets.replaceRoleSet to locate where to add these tests.
In `@packages/backend/src/api/endpoints/index.ts`:
- Around line 21-27: This index.ts barrel is adding many re-exports
(OrganizationPermissionApi, OrganizationRoleApi, OAuthApplicationsApi,
PhoneNumberApi, ProxyCheckApi, RedirectUrlApi, RoleSetApi) which violates the
no-barrel rule; remove these export lines from index.ts and update consumers to
import directly from each module's explicit path (e.g., import from
'./OrganizationPermissionApi' etc.), or if this file must remain a barrel for a
validated reason, add a clear exemption comment at the top of index.ts
referencing the exception and ensure reviewers approve it.
In `@packages/backend/src/api/endpoints/OrganizationPermissionApi.ts`:
- Around line 46-86: Public methods in OrganizationPermissionApi
(getOrganizationPermissionList, getOrganizationPermission,
createOrganizationPermission, updateOrganizationPermission,
deleteOrganizationPermission) lack explicit return type annotations; update each
method signature to declare the Promise return type that matches the request
generic (e.g., getOrganizationPermissionList():
Promise<PaginatedResourceResponse<Permission[]>>) so the SDK contract is
explicit, keeping method bodies unchanged and ensuring types align with the
this.request<...> generic used in each implementation.
In `@packages/backend/src/api/endpoints/OrganizationRoleApi.ts`:
- Around line 76-136: Add explicit Promise return types to all public methods on
OrganizationRoleApi: annotate getOrganizationRoleList, getOrganizationRole,
createOrganizationRole, updateOrganizationRole, deleteOrganizationRole,
assignPermissionToOrganizationRole, and removePermissionFromOrganizationRole
with their proper Promise<T> signatures (e.g.,
Promise<PaginatedResourceResponse<Role[]>> for getOrganizationRoleList,
Promise<Role> for single Role responses, Promise<DeletedObject> for delete).
Update the method declarations to return Promise<...> instead of relying on type
inference so the public API has explicit return types.
In `@packages/backend/src/api/endpoints/RoleSetApi.ts`:
- Around line 132-194: The public RoleSetApi methods lack explicit Promise
return types; update each method signature to declare its explicit Promise<...>
return type: getRoleSetList should return
Promise<PaginatedResourceResponse<RoleSet[]>>,
getRoleSet/createRoleSet/updateRoleSet/addRolesToRoleSet/replaceRoleInRoleSet
should return Promise<RoleSet>, and replaceRoleSet should return
Promise<DeletedObject>; adjust the signatures for getRoleSetList, getRoleSet,
createRoleSet, updateRoleSet, addRolesToRoleSet, replaceRoleInRoleSet, and
replaceRoleSet to include these explicit Promise return annotations.
In `@packages/backend/src/api/factory.ts`:
- Around line 46-120: Add an explicit exported return type for
createBackendApiClient: declare and export an interface (e.g. BackendApiClient)
that lists the public members returned (use the exact symbols from the factory
such as __experimental_accountlessApplications: AccountlessApplicationAPI,
actorTokens: ActorTokenAPI, agentTasks: AgentTaskAPI, apiKeys: APIKeysAPI, m2m:
M2MTokenApi, samlConnections: SamlConnectionAPI, etc.), then annotate the
function signature as createBackendApiClient(options: CreateBackendApiOptions):
BackendApiClient. Keep the interface members' types aligned with the existing
classes/constructors used in the return object so the public contract is locked
and the function no longer relies on type inference.
In `@packages/backend/src/api/resources/index.ts`:
- Around line 52-57: The index.ts barrel export was expanded to re-export
Permission, PhoneNumber, ProxyCheck, RedirectUrl, Role, and RoleSet which
violates the "avoid barrel files" guideline; revert those re-exports and instead
import the specific modules where needed (or, if this barrel is intentionally
allowed, add a documented, scoped exception comment above the exports explaining
why these resources must be re-exported). Locate the index.ts barrel (the file
that currently exports Permission, PhoneNumber, ProxyCheck, RedirectUrl, Role,
RoleSet) and either remove those export lines and use direct imports in callers,
or add a clear comment and update project documentation to justify keeping them.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Repository UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: 24124557-ba10-4117-9d0f-79d513879419
📒 Files selected for processing (15)
.changeset/orgs-rbac-backend-endpoints.mdpackages/backend/src/api/__tests__/OrganizationPermissionApi.test.tspackages/backend/src/api/__tests__/OrganizationRoleApi.test.tspackages/backend/src/api/__tests__/RoleSetApi.test.tspackages/backend/src/api/endpoints/OrganizationPermissionApi.tspackages/backend/src/api/endpoints/OrganizationRoleApi.tspackages/backend/src/api/endpoints/RoleSetApi.tspackages/backend/src/api/endpoints/index.tspackages/backend/src/api/factory.tspackages/backend/src/api/resources/Deserializer.tspackages/backend/src/api/resources/JSON.tspackages/backend/src/api/resources/Permission.tspackages/backend/src/api/resources/Role.tspackages/backend/src/api/resources/RoleSet.tspackages/backend/src/api/resources/index.ts
Comment on lines
+101
to
+106
| organizationPermissions: new OrganizationPermissionAPI(request), | ||
| organizationRoles: new OrganizationRoleAPI(request), | ||
| phoneNumbers: new PhoneNumberAPI(request), | ||
| proxyChecks: new ProxyCheckAPI(request), | ||
| redirectUrls: new RedirectUrlAPI(request), | ||
| roleSets: new RoleSetAPI(request), |
Contributor
There was a problem hiding this comment.
Document the new public client members for generated docs.
organizationPermissions, organizationRoles, and roleSets expand public/reference-facing API surface. Please add/align JSDoc for these additions and flag for Docs-team review if this impacts generated reference pages.
As per coding guidelines, "Clerk Docs generates reference documentation from JSDoc in clerk/javascript; public/reference-facing API changes should have accurate JSDoc and may need Docs-team review."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/backend/src/api/factory.ts` around lines 101 - 106, Add clear JSDoc
comments for the new public client members organizationPermissions,
organizationRoles, and roleSets in the API factory (the variables
OrganizationPermissionAPI, OrganizationRoleAPI, RoleSetAPI) describing their
purpose, public usage surface, and any return types or important behaviors;
ensure the JSDoc style matches existing entries for phoneNumbers, proxyChecks,
and redirectUrls so generated docs remain consistent, then mark the change for
Docs-team review so reference documentation in clerk/javascript can be updated
if necessary.
Source: Coding guidelines
|
Thank you @dmoerner ! |
wobsoriano
approved these changes
Jun 8, 2026
Member
wobsoriano
left a comment
There was a problem hiding this comment.
Looks good 👍🏼 thanks for adding
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Add Backend API support for managing instance-level organization RBAC.
createClerkClient()now exposes:organizationPermissions— list, get, create, update, and delete organization permissions.organizationRoles— list, get, create, update, and delete organization roles, plus assign/remove a permission to/from a role.roleSets— list, get, create, update, add roles to, replace a role in, and replace a role set.This was a request from Plain.
Checklist
pnpm testruns as expected.pnpm buildruns as expected.Type of change
Summary by CodeRabbit
Release Notes