Cleans up the `tableEditorApiAccessToggle` PostHog flag now that the gated UI is shipping to everyone. Follow-up to #45034 — the new project-creation checkbox makes the management UI a prerequisite, so no reason to keep it behind a flag. **Removed:** - `useDataApiGrantTogglesEnabled` hook - Old schemas-only multi-selector branch in the Data API settings page (the rich per-table / per-function toggles + default-privileges switch become the only UI) - Flag gate around the `<ApiAccessToggle>` section in the table editor side panel - Flag gates around `updateTableApiAccess` calls in the save pipeline (create / duplicate / update) - `tableEditorApiAccessToggleEnabled` telemetry property + stale JSDoc / docs references **Changed:** - `createTableApiAccessHandlerParams` no longer takes an `enabled` param — it was always `true` after removal ## To test - Integrations → Data API settings page: exposed tables, exposed functions, default-privileges toggle all render and save correctly - Table editor: creating, duplicating, and editing a table all run the expected Data API privilege updates - Project creation flow still works end-to-end (unchanged, but the submit telemetry no longer includes `tableEditorApiAccessToggleEnabled`) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Improvements** * API access configuration is now always available in the table editor and PostgreSQL settings, removing previous conditional gating. * Simplified the "Automatically expose new tables and functions" interface by consolidating UI branches. * **Documentation** * Updated telemetry guidance and examples with current feature-flag references. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
3.3 KiB
applyTo
| applyTo |
|---|
| apps/studio/**,packages/common/telemetry* |
Studio Telemetry Review Rules
All comments are advisory — suggest, do not request changes.
When to Flag Missing Telemetry
Use judgment — not every PR needs telemetry. But always flag when:
- Changes to
packages/common/telemetry-constants.ts— validate event naming, property conventions, and JSDoc accuracy. - PostHog feature flags without measurement. If a PR uses
usePHFlagor PostHog-backed hooks likeuseDataApiRevokeOnCreateDefaultEnabledto gate behavior, the flag state should be captured in a telemetry event so the rollout can be measured. Flag if the flag value isn't included in a relevanttrack()call. (Note:useFlagfromcommonreads ConfigCat flags, not PostHog — different system, different guidance.) - Feature-flagged rollouts without outcome tracking. If a flag gates new behavior, there should be telemetry on both the flag state and how users respond to the new behavior (e.g., toggle clicks, opt-in actions).
- Growth-oriented components adding user interactions without tracking — onboarding flows, setup wizards, upgrade CTAs, A/B experiment variants.
When tracking is missing, comment: "This adds a user interaction (or feature flag) that may benefit from tracking." Then propose an event name and useTrack() call.
Feature Flag Telemetry Pattern
When capturing a PostHog flag value for telemetry, read the raw flag via usePHFlag('flagName') — not through wrapper hooks that coerce undefined to false. Use conditional spread so the property is omitted (not false) when the flag store hasn't loaded:
const flagValue = usePHFlag<boolean>('myBooleanFlag') // for boolean flags
track('event_name', {
...(flagValue !== undefined && { myFlagEnabled: flagValue }),
})
For string-valued flags (e.g., experiment variants), use usePHFlag<string>('flagName') instead.
Event Naming
Format: [object]_[verb] in snake_case.
Prefer verbs already in use in packages/common/telemetry-constants.ts: opened, clicked, submitted, created, removed, updated, intended, evaluated, added, enabled, disabled, copied, exposed, failed, converted, closed, completed, applied, sent, moved.
Flag: unapproved verbs (saved, viewed, pressed), wrong order (click_product_card), wrong casing (productCardClicked), passive view tracking on page load (exception: _exposed events for A/B experiments).
Event Properties
- camelCase for new events; match existing convention when extending
- Self-explanatory names — flag generic (
label,value,name,data) - Check
telemetry-constants.tsfor consistency with similar events - Never track PII
Event Implementation
- Use
useTrackfromlib/telemetry/track— avoid introducing newuseSendEventMutationusage - New events need a TypeScript interface in
telemetry-constants.tswith@group Eventsand@sourceJSDoc tags (add@pagewhen applicable for page-specific events), added to theTelemetryEventunion
import { useTrack } from 'lib/telemetry/track'
const track = useTrack()
track('product_card_clicked', { productType: 'database', planTier: 'pro' })
Canonical standards: .claude/skills/telemetry-standards/SKILL.md