feat: Approve ai data processing in app for admins

[charlesvien]

Problem

The AI consent gate kicked admins out to the PostHog web app via openExternal to approve AI data processing. The flow is jarring and unnecessary, since PATCH /api/organizations/@current/ works under the current OAuth scope.

Changes

1. Add PostHogAPIClient.approveAiDataProcessing() that PATCHes /api/organizations/@current/
2. Replace the "Approve in PostHog" external link with an in-app "Approve AI data processing" button bound to useMutation
3. Invalidate the currentUser query family on success so the gate predicate re-evaluates and the screen unmounts automatically
4. Show a red error callout if the PATCH rejects
5. Track an AI_CONSENT_GRANTED_INAPP analytics event on success

How did you test this?

manually

Publish to changelog?

no

[charlesvien]

• feat: Approve ai data processing in app for admins #2367 👈 (View in Graphite)
• feat: Add switch to org button on plan usage screen #2366
• feat: Scope oauth tokens by org #2364 : 1 other dependent PR (#2365 )
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

T-Rex Logs

What T-Rex did

• T-Rex checked the approval client error path and confirmed non-OK PATCH responses are still rejected by the shared API fetcher, so the error callout path can be reached.
• T-Rex checked the in-app approval success path and found it only invalidates queries; it does not emit a distinct in-app consent success event.
• T-Rex checked the query invalidation path and found it targets the imported singleton client instead of the client from React Query context.
• T-Rex attempted to run the targeted component test file, but the local JavaScript runtime could not start the test runner because the available Node version lacks the required node:util.styleText export.

Artifacts

Targeted component test startup log

• This log helps verify why the targeted component test could not start due to the Node version limitation.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. apps/code/src/renderer/features/ai-approval/components/AiApprovalScreen.tsx, line 137-167 (link)

   Preserve role loading

   App passes isOrgAdmin === true, so the null loading state from useIsOrgAdmin() reaches this component as false. On a cold load, an admin can briefly see the non-admin “Ask an organization admin” copy until the role query resolves, and the mount-only gate analytics event records is_org_admin: false for that admin. Consider keeping an unknown/loading role state until the admin check is known.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: apps/code/src/renderer/features/ai-approval/components/AiApprovalScreen.tsx
   Line: 137-167
   
   Comment:
   **Preserve role loading**
   
   `App` passes `isOrgAdmin === true`, so the `null` loading state from `useIsOrgAdmin()` reaches this component as `false`. On a cold load, an admin can briefly see the non-admin “Ask an organization admin” copy until the role query resolves, and the mount-only gate analytics event records `is_org_admin: false` for that admin. Consider keeping an unknown/loading role state until the admin check is known.
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
apps/code/src/renderer/features/ai-approval/components/AiApprovalScreen.tsx:32-36
**Track approval success**

This success handler only invalidates the current user query. The PR adds a distinct in-app approval flow, but no success event is emitted from this path, and the existing `AI_CONSENT_APPROVED` event in `App.tsx` only fires when the gate disappears for any approval path. When an admin approves from this button, analytics cannot tell that the new in-app flow was used.

### Issue 2 of 3
apps/code/src/renderer/features/ai-approval/components/AiApprovalScreen.tsx:33-35
**Use context query client**

This invalidates the imported `queryClient` singleton instead of the nearest React Query client. Production currently appears to use the same singleton, but the component is now coupled to that module identity: a test, story, or alternate provider with its own `QueryClientProvider` will not refetch `currentUser` after approval, so the gate can stay visible with stale data even after the PATCH succeeds.

### Issue 3 of 3
apps/code/src/renderer/features/ai-approval/components/AiApprovalScreen.tsx:137-167
**Preserve role loading**

`App` passes `isOrgAdmin === true`, so the `null` loading state from `useIsOrgAdmin()` reaches this component as `false`. On a cold load, an admin can briefly see the non-admin “Ask an organization admin” copy until the role query resolves, and the mount-only gate analytics event records `is_org_admin: false` for that admin. Consider keeping an unknown/loading role state until the admin check is known.

_{Reviews (1): Last reviewed commit: "drop dead ok guard, broaden currentUser ..." | Re-trigger Greptile}

[charlesvien]

Merge activity

• Jun 2, 6:04 PM UTC: @charlesvien merged this pull request with Graphite.