feat(google-workspace-admin): add Admin SDK Directory and Reports integration

[waleedlatif1]

Summary

Adds a Google Workspace Admin block covering the Admin SDK Directory API surfaces the Google Groups integration never reached — users, org units, admin roles, and devices — plus the Reports API audit and usage endpoints. This is what joiner/mover/leaver agents were missing.

37 tools:

• Users — list, get, create, update, delete, suspend, unsuspend, reset password, move org unit, make/revoke admin, sign out, aliases, and the OAuth application tokens a user has issued
• Org units — list, get, create, update, delete
• Roles — list roles, get role, list/create/delete role assignments
• Devices — mobile list/get/action, ChromeOS list/get/update/batch status change
• Reports — activities.list, customerUsageReports.get, userUsageReport.get

OAuth wiring mirrors google-groups: a google-workspace-admin service on the shared Google client, service-account fallback, and per-endpoint scopes.

Notes for reviewers

• The icon is a generic placeholder. Google publishes no standalone Admin console brand asset, so GoogleWorkspaceAdminIcon is a neutral monochrome directory glyph drawn with currentColor, marked TODO in the source until a real brand mark is supplied.
• BatchChangeChromeOsDeviceStatus was added to restore ChromeOS offboarding. The deprecated chromeosdevices.action endpoint was deliberately not used; dropping it had left deprovision/disable/re-enable — the whole Chromebook offboarding path — with no replacement. The successor is fully specified in the discovery document: up to 50 device IDs, three status actions, four non-deprecated deprovision reasons.
• admin.directory.device.mobile.action was removed as redundant. mobiledevices.action accepts either it or admin.directory.device.mobile, and the latter is already declared for list and get, so the narrower scope only widened the consent screen without unlocking anything.
• Nothing was live-tested against a Workspace tenant. Every endpoint path, HTTP method, query parameter name, enum value, request body field, and response envelope field was verified against Google's machine-readable discovery documents (directory_v1 and reports_v1) — not against prose docs and not against a live account. The one thing discovery cannot confirm is the mobiledevices.action action values (MobileDeviceAction.action is a bare string with no enum); those come from prose docs only and are called out here rather than presented as verified.

Validation findings fixed in this PR

A final validation pass against the discovery documents caught seven real defects, all in the last commit:

Enum casing (would have returned 400 Invalid Value on every call). The Directory API does not use one casing convention — users.list takes familyName and basic, while the device collections take SERIAL_NUMBER and BASIC, and sortOrder is uppercase everywhere. Five parameters were sent in the wrong style: users.list orderBy, users.list/users.get projection, orgunits.list type, chromeosdevices.list orderBy, and mobiledevices.list orderBy. Each allowed set is now a constant taken verbatim from discovery, the param interfaces derive their unions from those constants, and normalizeEnumValue matches case-insensitively and ignores underscores so a caller writing either style still reaches the API with the spelling that endpoint wants. An unrecognized value now fails with the allowed set instead of a bare 400.

deprovisionReason was never enforced. It was required: true on the subBlock but required: false on the tool, and the serializer validates neither once a name is claimed by a tool param — so a DEPROVISION batch with a blank reason serialized fine and failed at Google. The body builder now gates on the action: required for DEPROVISION, never sent for the other two.

Five PATCH fields could silently wipe data. update_chromeos_device and update_org_unit guarded their optional strings with !== undefined while the rest of the integration guards on truthiness. A subBlock that was touched and then cleared serializes as '', so those fields would erase the annotation, notes, or description rather than leave them alone.

Test plan

• bun run type-check clean
• bun run check:audits — 26 audits, all passing except four that need binaries this worktree lacks (turbo, tsc, biome)
• bun run tool-metadata:check, bun run integration-catalog:check, bun run check:api-validation:strict pass
• bun test apps/sim/lib/integrations/availability.server.test.ts apps/sim/lib/integrations/credential-display.test.ts — 50 pass
• Docs, integrations.json, and the docs icon mirror regenerated and byte-identical to the app copy

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview	Aug 15, 2026 11:15pm

[cursor]

PR Summary

High Risk
Exposes destructive and privileged Admin SDK actions (user delete, super-admin grants, session/token revocation, device wipes/deprovision) behind new OAuth scopes; misconfiguration or workflow bugs can cause broad account or device impact.

Overview
Adds a new Google Workspace Admin workflow block and catalog entry wired to the Google Admin SDK (Directory + Reports), with 37 operations spanning users, org units, roles, mobile/ChromeOS devices, audit activities, and usage reports.

Product surface: A large google_workspace_admin block defines operation-specific subblocks, canvas sentences, templates/skills, and param mapping to google_workspace_admin_* tools. Docs (google_workspace_admin.mdx), integration metadata, and nav (meta.json) are added; a placeholder GoogleWorkspaceAdminIcon is registered in docs and app icon maps.

Auth & credentials: New OAuth provider google-workspace-admin (shared Google client, offline consent) with Directory/Reports admin scopes, env capability entry, service-account fallback via google-service-account, and updated Google family credential display count (14 integrations).

^{Reviewed by Cursor Bugbot for commit 98c7ba7. Configure here.}

[greptile-apps]

Greptile Summary

Adds a Google Workspace Admin integration spanning Directory and Reports APIs, including OAuth/service-account wiring, block registration, generated metadata, and documentation.

• Adds tools for users, organizational units, roles, mobile and ChromeOS devices, audit activities, and usage reports.
• Handles partial ChromeOS batch failures as top-level tool failures while preserving successful and failed device IDs for targeted retries.
• Registers the integration across the application and documentation catalogs.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the previously reported ChromeOS batch partial-failure path now returns a failed tool result and stops generic workflow continuation.

Important Files Changed

Filename	Overview
apps/sim/tools/google_workspace_admin/batch_change_chromeos_device_status.ts	The prior partial-failure issue is addressed by detecting item-level errors, returning top-level failure, and preserving per-device outcomes and retry IDs.
apps/sim/blocks/blocks/google_workspace_admin.ts	Defines the new block’s operation-specific UI, parameter mapping, tool selection, and declared outputs.
apps/sim/tools/google_workspace_admin/types.ts	Provides shared parameter and response types for the new Google Workspace Admin tools.
apps/sim/lib/oauth/oauth.ts	Extends shared OAuth configuration for the Google Workspace Admin service.
apps/sim/tools/registry.ts	Registers the new Admin SDK and Reports API tools for runtime dispatch.

_{Reviews (2): Last reviewed commit: "fix(google-workspace-admin): fail the Ch..." | Re-trigger Greptile}

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 98c7ba7. Configure here.}