[brionmario]

Purpose

Make the management API usable from apps that already own a data layer, and cover all of it. The ThunderID Console fetches with TanStack Query, so it needs the SDK's management calls as plain functions it can put inside its own queryFn/mutationFn, with its own cache keys and invalidation. Its lists then feed the SDK's Base* admin components through their render props.

The per-resource hooks (useGetUsers, useCreateGroup, ...) duplicated what any data library already does and had no real users outside the SDK's own components, so they are no longer public. The connected admin components (UserList, GroupMembers, ...) keep working unchanged for apps without a data layer.

Approach

• API functions are the public surface. They live in @thunderid/javascript and are re-exported through browser, react and vue. Each takes a ManagementRequestConfig (baseUrl, url, fetcher).

• useManagementRequestConfig(collection) (React, Vue, Next.js) returns the provider's base URL, the endpoint override for that collection, and the fetcher. A call therefore uses the same transport as the components: the server action in Next.js, the module's proxy in Nuxt. In React the config is memoized, so it can sit in a dependency list.

• Internal data layer. The connected components inline their queries and mutations on the generic useResourceQuery/useResourceMutation/useManagementEndpoint. Query keys and invalidation are the same as the removed hooks had, and no per-resource hook files remain.

• Administration flows. administrationMode: 'flow' (default 'native') runs the administration flow the server configures for these operations:

  • user, group, role and application deletion
  • group member removal and role assignment removal (one run per item)
  • role permission removal
  • client secret regeneration

  The flow is resolved from /server-config/flow and /flows?flowType=ADMINISTRATION. When no flow is configured, the call goes direct. A configured but missing flow, or a refused or incomplete step, throws AdministrationFlowError carrying the step's error.

• New functions:

  • users: getUserUsages, updateUserCredentials
  • user types: getUserType, createUserType, updateUserType, deleteUserType
  • agent types: getAgentType, updateAgentType
  • applications: previewCimdDocument, regenerateClientSecret, regenerateFlowSecret
  • agents: regenerateAgentSecret
  • getUserTypes is now re-exported from react and vue too.

• Full coverage of the management API. Every identity resource has list, get, create, update and delete:

  • applications, users, groups, roles, agents, user types and agent types
  • organization units, by id or by handle path (getOrganizationUnitByPath), with their child units, users, groups and roles
  • resource servers, with their resources and actions

  Users and applications gain sharing policies and overlay rules. Suspend, unsuspend and unlock run only through their administration flows (runAccountLifecycleFlow) and fail with a documented error when no flow is configured.

• Configuration resources. Connections, flows, notification templates, design themes (*DesignTheme*, since createTheme already exists) and layouts, translations, server configuration, gateways, variables and secrets, configuration versions, and import and export. A secret's value is write-only.

• Application components. ApplicationList, ApplicationCreate and ApplicationDetails for React, Vue, Next.js and Nuxt, each with a Base variant and a custom render. The list shows a translated status column when the server returns one. Their strings (admin.applications.*) are in every bundled locale. The OAuth form helpers they share (getApplicationOAuthConfig, parseRedirectUris, toCreateApplicationRequest, ...) live in @thunderid/javascript, one per file. Application writes leave out the read-only status.

• Server side. The Node management client gains an applications group, and the Next.js and Nuxt relay allowlist accepts the applications collection. CIMD preview is a direct server call and stays off the relay allowlist.

• Server error codes. ThunderIDAPIError.serverError carries the server's error envelope (code, message, description with params), so an app can show the server's translated error.

• Secret regeneration: regenerateClientSecret refuses an application without an OAuth client (regenerateClientSecret-ValidationError-001), rather than returning a secret it never saved. regenerateAgentSecret restates the agent's delegated flag, derived from its grant types, because the server doesn't store it. It also leaves the display-only ouHandle out of the update.

• One function per file: each administration flow function (runAdministrationFlow, executeAdministrationFlow, resolveAdministrationFlowId, ...) has its own module under api/management/administration/, and the playground data layers are split the same way.

• Display data: getRoles, getRole, getUserTypes and getAgentTypes now send include=display, like the other getters, so organization unit handles resolve.

• Nuxt: the module auto-imported composables that @thunderid/vue no longer exports, which would fail an app's build. It now auto-imports useGrantedPermissions and useManagementRequestConfig. A test checks that every auto-imported name is exported.

• Better Auth: the adapter moves to Better Auth 1.7.13, which fixes GHSA-965c-763c-88jm and GHSA-r4xp-prcw-77qf, the two advisories failing pnpm audit. That release drops accountIssuer, so the provider config leaves it out; a discovery provider uses the discovered issuer anyway. It now sets requireIdTokenVerification, so the provider isn't registered when discovery can't supply the issuer and keys to verify ID tokens.

• Playgrounds: the React, Vue, Nuxt and Next.js playgrounds now demonstrate the API functions with a small local data helper.

Related Issues

• Management operations support for ThunderID SDKs thunderid#5162

Related PRs

• Move the Console's configure packages onto the SDK's management API functions thunderid#6119 (the Console moves onto these functions)
• Samples: none affected; no sample uses a removed hook.

SDK parity

• Complete the management operations and add application components ios-sdks#35
• Complete the management operations and add application components android-sdks#43
• Complete the management operations and add application components flutter-sdks#54

Checklist

• Followed the contribution guidelines.
• Manual test round performed and verified.
• Documentation provided. (Add links if there are any)
• Tests provided. (Add links if there are any)
  • Unit Tests
  • Integration Tests
• Breaking changes. (Fill if applicable)
  • Breaking changes section filled.
  • breaking change label added.
• Cross-SDK parity. Exactly one of parity/prs-raised or parity/prs-not-needed added.
  • If parity/prs-raised, the port links are posted as a reply on the parity check's comment.

Security checks

• Followed secure coding standards.
• Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration

• Source mode: Auto
• Repository: thunder-id/javascript-sdks
• Branch: main
• File: .coderabbit.yaml
• Commit: 80ddfa4
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: c0a2a526-9b72-43f4-83c3-18ccf8de6d80

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🔀 Cross-SDK feature parity, ports raised

This pull request is labelled parity/prs-raised, so the capability it introduces is expected in the other ThunderID SDKs as well.

Ports (DO NOT EDIT)

• thunder-id/ios-sdks, iOS => #35
• thunder-id/android-sdks, Android => #43
• thunder-id/flutter-sdks, Flutter => #54

3 of 3 sibling SDKs accounted for.

Every sibling SDK is accounted for.

The contract is in the SDK development specification.