[brionmario]

Purpose

Adds agent, group, role and user management to the Android SDK: the management operations and Compose admin components for each. Roles carry their permissions, and the SDK can read the permissions an access token grants to decide what to show. This brings it in line with the equivalent JavaScript change (thunder-id/javascript-sdks#130).

Approach

• Endpoints: groups, roles, agent types and user types join the existing management endpoint settings. Each collection defaults to {baseUrl}/{collection}.

• Management APIs:

  • Groups and roles: list, get, create, update and delete, plus group members and role assignments.
  • Agent groups, agent roles, agent types, user groups and user types.
  • The transport gains sub-resource reads and actions for members and assignments.

• Permissions: helpers that read the permissions an access token grants and match them the way the server does (system:user covers system:user:view), and granted permissions exposed through the SDK state.

• UI: Compose admin components for users, groups, roles and agents (list, create, details, members, permissions and assignments), each with a Base* variant, with their strings.

• Custom rendering: every admin component, Base* and connected, takes an optional trailing content lambda, the same pattern as BaseSignIn, and renders it in place of its own UI. It receives the component's state: rows, paging and selection for a list; values, setters, submit and validity for a form; the record and the allowed actions for details, members, assignments and permissions.

• Search and filters: UserList and AgentList search on the server (users by username or email, agents by name), and RoleAssignments filters by assignee type. The server matches one attribute exactly, so the search applies on submit. The agents API gains filter, and ManagementFilter.equality builds the expression. Groups, roles and group members have no server filter, so they stay unfiltered.

• Layout: the Compose components are grouped by function instead of by kind: auth/ (with buttons/, flow/ and guards/), account/, admin/ and common/. The data layer stays in management/. See Breaking Changes.

Related Issues

• Part of Management operations support for ThunderID SDKs thunderid#5162
• Resolves the SDK part of:
  • Agent management operations and components for the SDKs thunderid#5999 (agents)
  • Group management operations and components for the SDKs thunderid#5997 (groups)
  • Role management operations and components for the SDKs thunderid#5998 (roles)
  • User management operations and components for the SDKs thunderid#5996 (users)

Related PRs

• Add management operations for agents, groups, roles and users javascript-sdks#130
• Add management operations for agents, groups, roles and users ios-sdks#33
• Add management operations for agents, groups, roles and users flutter-sdks#51
• Add management operations for applications, users, and agents #35 (the earlier application, user and agent operations)
• [Spec] Specify backend sign-in, group and role management, and admin components for the SDKs thunderid#6080 (the specification for these operations, admin components, the custom render, and sample upkeep)
• Move the Android quickstart to Android SDK v1.6.0 samples#14 (the Android quickstart moves to the new component packages; a draft until this ships)

Samples-Ref: refs/pull/14/head

Playground

The playground exercises the new APIs:

• capability checks for each new resource and for permissions
• explorer stories for every admin component, with sample data, live variants and Compose snippets
• a permissions view in the session inspector
• a Custom rendering group that draws UserList, GroupCreate and UserDetails with Compose views through the trailing content lambda
• a card showing where each management collection resolves

THUNDERID_ENDPOINT_<KEY> overrides one management collection's URL. The SDK gaps the playground hit are listed in its README.

Screenshots

From the playground on the Android emulator.

Admin components

UserList	UserDetails	GroupMembers

RoleAssignments

Custom rendering through the content lambda

UserList as ListItems	GroupCreate, Material form	UserDetails, Material card

Verified locally: ./gradlew ktlintCheck assembleDebug in the playground, which builds the SDK as an included build, and ./gradlew testDebugUnitTest ktlintCheck for the SDK. The Custom rendering stories were not run on an emulator. The live management checks have only run signed out so far.

[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/javascript-sdks, JavaScript (React, Vue, Nuxt, Next.js, Express, React Router, TanStack Router, Browser, Node) => #130
• thunder-id/ios-sdks, iOS => #33
• thunder-id/flutter-sdks, Flutter => #51

3 of 3 sibling SDKs accounted for.

Every sibling SDK is accounted for.

The contract is in the SDK development specification.

[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/android-sdks
• Branch: main
• File: .coderabbit.yaml
• Commit: 12cfc19
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: e0b28364-5126-426d-88d0-e0aebc6fc40f

• 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.}