feat(identity): onboard Users service with getById

[Sarath1018]

Summary

PR 1 of 3 splitting the Identity user management onboarding (#609 is the final slice). Introduces the modular Users service (@uipath/uipath-typescript/users) with the first method:

SDK method	Endpoint
getById(userId)	GET /api/User/{userId}

Design notes

• Org-level routing: Identity URLs have no tenant segment, so endpoints use a ../identity_ base (IDENTITY_ORG_BASE) to collapse the tenant segment ApiClient inserts — same pattern as the notification service.
• Live-API findings encoded (Swagger spec is wrong on these): type/category are returned as numeric codes, not string enums → mapped to UserType/UserCategory enums; internal legacyId is dropped from the SDK response.
• Transforms: API is already camelCase; semantic renames creationTime→createdTime, lastModificationTime→lastModifiedTime, groupIDs→groupIds.
• Full scaffold included: models/types/constants, subpath export wiring (package.json, rollup.config.js), TypeDoc export, mkdocs nav, oauth-scopes entry.

Testing

• Unit: 3 tests (retrieval, transform completeness incl. absence of original API fields, error propagation)
• Integration: 2 tests passing against live alpha — uses a configured IDENTITY_TEST_USER_ID fixture (self-provisioning arrives in PR 2 with create())
• typecheck ✓, oxlint ✓, full unit suite passing

Stack

1. This PR — service scaffold + getById
2. feat/identity-users-crud — updateById, deleteById, create + bound entity methods
3. feat/identity-users (feat(identity): add invite to Users service #609) — invite

🤖 Generated with Claude Code

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://UiPath.github.io/uipath-typescript/pr-preview/pr-616/
Built to branch gh-pages at 2026-07-21 06:58 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[claude]

Review findings

Two issues flagged as inline comments:

1. package.json:3 — Version downgraded from 1.5.5 to 1.5.4. Feature PRs must never touch the version; version bumps belong in a dedicated PR. Revert to 1.5.5.

2. unified-setup.ts:69 — subscriptions is replaced by users in TestServices and createV1Services instead of being added alongside it. The existing subscriptions.integration.test.ts calls getServices().subscriptions, so this removal will cause a TypeScript error and silently break that test suite when re-enabled. Add users as a new field; keep subscriptions.

[claude]

Review summary

One new finding posted as an inline comment this run:

users.models.ts:37-38 — {@link UserGetResponse} is orphaned on its own line after @returns instead of being inline. TypeDoc renders both lines concatenated without a separator, producing "Promise resolving to the user UserGetResponse". Inline placement + a brief content description fixes both the rendering and the missing "what the response includes" convention requirement.

---

The core implementation (model/types/constants, transform pipeline, endpoint wiring, unit + integration tests) looks correct.

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.

[claude]

The JSDoc says "User as returned by the Identity user management API" but RawUserGetResponse is the SDK-facing shape (after field renames and numeric→enum mapping), not the raw API wire format. The actual API response shape is RawUserEntry in users.internal-types.ts — which has creationTime, groupIDs, and numeric type/category codes.

Per CLAUDE.md: Raw{Entity}GetResponse types describe the shape before method attachment, not the literal API wire format. A contributor implementing a future method (e.g. getAll) who reads this comment could incorrectly assume the API returns createdTime / UserType values and skip the transform step.

Suggested change

	export interface RawUserGetResponse {
	/**
	* SDK-facing user shape returned by {@link UserServiceModel.getById}.
	*
	* Field selection: `legacyId` (an internal platform synchronization field) is returned
	* by the API but dropped from the SDK because it has no use for an application developer.
	*/
	export interface RawUserGetResponse {

[claude]

Review summary

One new finding posted as an inline comment this run:

users.types.ts:41 — The JSDoc on RawUserGetResponse says "User as returned by the Identity user management API" but the type uses SDK field names (createdTime, groupIds) and enum types (UserType, UserCategory) rather than the raw API wire format. The raw API shape lives in RawUserEntry (internal-types.ts). A future contributor implementing getAll could read this comment and incorrectly skip the transform step. Suggested fix: describe it as the "SDK-facing user shape" instead.

---

The rest of the implementation looks correct — transform pipeline, enum mappings, internal field stripping, subpath export wiring, and tests all follow the SDK conventions.

[claude]

Non-standard use of the transform callback to chain a second applyDataTransforms call. The transform option is designed for arbitrary post-processing, not for chaining field-value maps; using it this way is unusual and makes extending the pipeline (e.g., a third enum field) require further nesting.

The conventional pattern throughout the SDK is two sequential calls:

Suggested change

	return applyDataTransforms(renamed, {
	field: 'type',
	valueMap: UserTypeMap,
	transform: (data) =>
	applyDataTransforms(data, { field: 'category', valueMap: UserCategoryMap }),
	});
	const withType = applyDataTransforms(renamed, { field: 'type', valueMap: UserTypeMap });
	return applyDataTransforms(withType, { field: 'category', valueMap: UserCategoryMap });

[claude]

Review summary

One new finding posted as an inline comment this run:

users.ts:42–47 — applyDataTransforms is chained via the transform callback instead of two sequential calls. The transform option is for arbitrary post-processing, not for stringing together field-value maps; it reads less clearly and makes adding a third enum field require further nesting. Sequential calls are the SDK-wide convention.

---

All previously-raised threads were confirmed fixed (version downgrade reverted, subscriptions retained alongside users in TestServices, downloadCitationSource() not removed from oauth-scopes.md, {@link} inlined in @returns). The core implementation — transform pipeline, endpoint wiring, unit + integration tests, JSDoc — looks correct.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud