218 Commits

Author	SHA1	Message	Date
Paul Rastoin	217cf650aa	Decide workspace destiny from live data and all sub (#22943) ... ## Context A production customer was stuck on the billing settings page: their workspace was `SUSPENDED` (with `suspendedAt` set) while their subscription was `active` in the database. ## Problem Stripe webhook events can be delivered out of order or processed concurrently ([Stripe explicitly does not guarantee ordering](https://docs.stripe.com/webhooks#events-ordering)), and `BillingWebhookSubscriptionService.processStripeEvent` made its suspend/reactivate decision from stale and incomplete data: - The decision used the **event payload's** subscription status, while the subscription row was upserted from a **live Stripe fetch** — so the two could diverge. Around trial end, Stripe emits `active → past_due` then (once the customer pays) `past_due → active` within a short window. If the stale `past_due` event is processed last, it suspends the workspace while writing an `active` subscription to the DB. Nothing self-heals from that state: the workspace stays suspended while the cleanup cron warns and eventually soft-deletes it. - The decision only looked at the **event's own subscription**, but suspension is a workspace-level decision and a Stripe customer can hold several subscriptions (plan switch, cancel-then-resubscribe). A `customer.subscription.deleted` event for the old subscription is *genuinely* canceled — only the sibling subscription proves the customer is still paying. - The workspace snapshot was read at the top of the handler, before several slow awaits, so a concurrent event could change it mid-flight. ## Fix Every event now converges the workspace to the current Stripe state, regardless of delivery order: - **Live input**: fetch the customer's not-ended subscriptions from Stripe (`subscriptions.list` without a `status` param excludes the unbounded canceled history server-side; an explicit `NOT_ENDED_SUBSCRIPTION_STATUSES` filter additionally drops `incomplete_expired`, which would otherwise block suspension forever since it is neither suspend-worthy nor activating). The event's subscription is taken from that list, or fetched directly by id when absent (deletion events, deleted customers) — same retrieve the code used before. The DB upsert uses this live object, never the payload. - **Workspace-level decision over all live subscriptions**: suspend only when **every** subscription warrants it, reactivate as soon as **one** is activating (`active`/`trialing`), and deliberately do nothing in between — e.g. a `past_due` subscription in its payment-retry grace period blocks suspension without triggering reactivation. - **Guarded transitions (compare-and-swap)**: `WorkspaceService.suspendWorkspace`/`reactivateWorkspace` now apply their UPDATE only when the workspace is still in a state the transition is valid from, and return whether they applied. Repeated suspensions keep the first `suspendedAt` so the cleanup countdown stays anchored to the original suspension date; the deletion-warning cleanup job is only enqueued when a reactivation actually applied. The suspend path re-reads the workspace right before deciding and switches exhaustively on `activationStatus` (`assertUnreachable` in `default`), preserving the previous behavior including suspend-over-reactivate precedence. ## Tests Unit tests cover the incident scenario and its neighbors: a stale `past_due` event after payment reactivates instead of suspending; a live `unpaid` state suspends even when the payload says `active`; a canceled subscription event does not suspend (and reactivates) when a sibling `active`/`trialing` subscription exists; a sibling in `past_due` grace blocks suspension without reactivating; the direct-retrieve fallback handles subscriptions absent from the customer list; the guarded reactivation skips the cleanup job when it did not apply; and soft-deleted workspaces are never transitioned.	2026-07-16 14:09:09 +02:00
Charles Bochet	8e03921372	Add CREATED workspace activation status (read path + enum migration) (#22904) ... ## Context Since v2 onboarding (#22303), workspaces are activated **before** the billing plan step (now the last onboarding step). Users abandoning at the plan step leave ACTIVE workspaces with a Stripe customer but no subscription (~60–110/day on cloud, 935+ so far), and no cleanup mechanism ever touches them: billing webhooks never fire (no subscription), the suspended-workspaces cron only handles SUSPENDED, the onboarding cron only handles PENDING_CREATION/ONGOING_CREATION. Target lifecycle (across two PRs): `PENDING_CREATION → ONGOING_CREATION → CREATED → ACTIVE → SUSPENDED → deleted`. **`CREATED`** = the workspace schema is provisioned but onboarding is not complete — no billing subscription yet. It is **not** considered active: | Concern | CREATED behavior | |---|---| | Sign-in / invited teammates joining | allowed (invite-team step precedes the plan step) | | Member + metadata loading (app shell) | allowed (user must finish onboarding) | | Permissions | real permission checks (no PENDING-style bypass) | | Version upgrades / workspace migrations | **included** (schema must not drift) | | Messaging/calendar/workflow/etc. crons | **excluded** — no background processing until a plan is chosen | | PLAN_REQUIRED onboarding lock | unchanged (still derived from subscription existence) | ## What this PR does (read path only) The enum addition ships as a **slow** instance command, which can run after deploy — so nothing in this PR ever **writes** `CREATED`. The write path (setting it at activation, the cleanup sweep, the backfill of the existing zombie cohort) is a follow-up PR that ships once this migration has run everywhere. - **twenty-shared**: `CREATED` enum value; `PROVISIONED_WORKSPACE_ACTIVATION_STATUSES` + `isWorkspaceProvisioned` ("schema exists": CREATED | ACTIVE | SUSPENDED), replacing `isWorkspaceActiveOrSuspended` — all call sites (server member loading, access-token workspace-member lookup, front metadata-store gates) meant "has schema/members". - **Slow instance command** (2.22.0): swaps `core.workspace_activationStatus_enum` using the rename→recreate→alter-column idiom. The CHECK constraints on `core.workspace` embed casts to the enum type and would break the swap — the command captures them from `pg_constraint`, drops them, swaps the type, and restores them. - **Pre-migration-safe queries**: Postgres rejects `IN ('CREATED', ...)` when the enum value does not exist yet — even for reads, and the instance-command runner itself queries provisioned workspaces before migrating (a fresh database could never initialize). All provisioned-status filters go through a new `activationStatusIn` util comparing on `"activationStatus"::text`, valid before and after the migration. - **Upgrade path**: workspace iterator, command runner, upgrade-status and workspace-version services iterate CREATED workspaces. Since they now cover more than ACTIVE/SUSPENDED, the stale names were renamed to `ProvisionedWorkspaceCommandRunner`, `hasProvisionedWorkspaces`, `getProvisionedWorkspaceIds`, `loadProvisionedWorkspaces` (the mechanical import rename in old version-command dirs is why this PR carries the `ci:allow-previous-version-upgrade-mutation` label). - **Sign-in**: `throwIfWorkspaceIsNotReadyForSignInUp` accepts CREATED so invited members can join during onboarding (join authorization itself is unchanged — enforced upstream in `checkAccessForSignIn`); `activateWorkspace` idempotent-retry accepts CREATED as a terminal state. - **Transitions out of CREATED** (only write ACTIVE — safe to ship now, dead until the write path lands): the Stripe webhook reactivation branch also promotes CREATED, and `syncSubscriptionToDatabase` promotes synchronously; both gated on `WORKSPACE_ACTIVATING_SUBSCRIPTION_STATUSES` (Active/Trialing — extracted from `shouldReactivateWorkspace`, behavior-preserving) so an `incomplete` subscription created by the payment-intent flow before payment never promotes the workspace. - Deliberately untouched: all background crons, permission guards, JWT strategy, PLAN_REQUIRED logic, admin panel (renders the raw status string). ## Follow-up PR (after this migration has run) 1. `activateWorkspace` sets `hasWorkspaceAnySubscription ? ACTIVE : CREATED` (billing disabled → always ACTIVE, self-hosted unchanged). 2. Cleanup: suspend CREATED workspaces older than N days (config var), handing them to the existing suspended pipeline (warn → soft-delete → destroy). 3. Backfill: cloud-only slow command moving ACTIVE workspaces with no billingSubscription row (created since Jul 1) to CREATED. ## Verification - Migration exercised against a real database via the command class: up → down → up; `enum_range` and `pg_get_constraintdef` checked after each step (constraints restored against the new type, `DEFAULT 'INACTIVE'` preserved). - Pre-migration safety exercised for real: with the migration rolled back (enum without CREATED), `run-instance-commands` — the exact fresh-database CI path that failed before the `::text` fix — completes cleanly. - End-to-end with a workspace manually set to CREATED and the branch server+front running: sign-in issues tokens, `currentUser` loads workspaceMember(s), the full app loads with no console errors; GraphQL returns `activationStatus: CREATED`. - Workspace creation ran end-to-end locally in **both billing modes** on this branch: - billing disabled: signup → workspace creation → ACTIVE immediately → onboarding completes with no plan step → app loads (unchanged behavior); - billing enabled (Stripe test mode): signup creates the Stripe customer eagerly → activation ends ACTIVE → subscription-less workspace is pinned to the plan-required page → no-card trial checkout creates a `trialing` subscription via `createDirectSubscription`/`syncSubscriptionToDatabase` → app loads. - `twenty-shared` unit tests, server specs on touched services, `lint:diff-with-main` and `typecheck` for shared/server/front all green; full CI green.	2026-07-15 17:03:17 +02:00
Abdul Rahman	58fcb3cb0f	drop nestjs-query IDField from standalone DTOs/entities (#22881) ... ## What Replaces `@IDField(() => UUIDScalarType)` from `@ptc-org/nestjs-query-graphql` with the native `@Field(() => UUIDScalarType)` (`@nestjs/graphql`) across 50 DTOs and entities that are **not** wired to a nestjs-query auto-resolver. This continues the incremental migration off `@ptc-org/nestjs-query`. ## Why These 50 types only used `IDField` to type their `id` column as a UUID scalar. Since none of them are attached to a `NestjsQueryGraphQLModule.forFeature` resolver, `IDField` carries no extra behavior here — it's a plain field decorator. Co-authored-by: Abdul Rahman <abdulrahmancodes@users.noreply.github.com>	2026-07-14 17:16:59 +02:00
Félix Malfait	0755855768	fix(billing) - skip paying upgrade invoices already settled at finalization (#22705) ... ## Problem Upgrading resource credits fails with `Invoice is already paid` whenever the one-off upgrade invoice resolves to a $0 amount due. That is the case for internal workspaces on the `Twenty Internal - 100% FREE` coupon, and for customers whose credit balance covers the price difference. Reproduced on an internal workspace (5 to 20 credits upgrade): 1. `createImmediateUpgradeInvoice` creates the invoice for the $20 diff and finalizes it with `auto_advance: true` 2. The 100% coupon brings the amount due to $0, and Stripe settles zero-due invoices at finalization ("Invoice was finalised and automatically marked as paid because the amount due was US$0.00") 3. The explicit `stripe.invoices.pay()` that follows is rejected with a 400 `invalid_request_error`: "Invoice is already paid" 4. The error propagates, so the mutation aborts before `runSubscriptionUpdate`: the Stripe subscription item stays on the old 5 credits price while the upgrade invoice already exists 5. Every retry creates a new invoice item + invoice and fails the same way, leaving stray $0 invoices on the customer ## History Third pass on this code path: - #21097 treated it as a race with `auto_advance` and switched finalization to `auto_advance: false`. Zero-due invoices are settled at finalization regardless of that flag, so the failure remained. - #21450 restored `auto_advance: true` and swallowed the error when `error.code === 'invoice_already_paid'`. Stripe does not send that code for this failure (it is not in its documented error codes; the response only carries the message), so the guard never matched and the error was always rethrown. ## Fix Rely on invoice status instead of error codes: - `finalizeInvoice` returns the finalized invoice; when it comes back `paid` (the zero-due case), skip `pay` entirely - if `pay` still fails (the genuine auto_advance race from #21097), re-retrieve the invoice and only rethrow when it is actually unpaid ## Tests Unit tests for `createImmediateUpgradeInvoice`: - open invoice after finalization gets paid - invoice settled at finalization skips `pay` - `pay` failure with a meanwhile-paid invoice is swallowed - `pay` failure with an unpaid invoice is rethrown --- _Generated by [Claude Code](https://claude.ai/code/session_01BwoUffgasLUsXsaGuANsAP)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22705?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-07-09 09:09:58 +02:00
Raphaël Bosi	2c0e0b2eac	Create billing customer at signup so onboarding rewards are credited (#22633) ... ## Problem Onboarding credit rewards (install apps, import contacts, invite team) were silently dropped. They credit the workspace balance via `billingCustomer.increment(...)`, but no `billingCustomer` row exists until the plan step (it's created lazily when the first subscription is set up, which is after those steps). So the increment affected 0 rows and the credit was lost. A user installing 3 apps saw only the trial grant, not the expected +1.5 credits. ## Fix Create the Stripe customer + `billingCustomer` row eagerly at signup via a new `BillingCreditService.ensureBillingCustomer`, called from `signUpOnNewWorkspace` after the workspace transaction commits. It is idempotent, guarded by `IS_BILLING_ENABLED`, and non-blocking (failures are logged, not thrown). The later subscription flow reuses this customer (no duplicate Stripe customer), and trial eligibility is unchanged since the customer has no subscriptions yet. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22633?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-07-07 14:51:53 +00:00
neo773	6f64be5751	Gate and meter email group: enterprise license (self-host) + credits (cloud) (#22390) ... Email group (marketing email) was gated only by the `IS_EMAIL_GROUP_ENABLED` feature flag with no server-side enforcement. This adds real gating, split by deployment: - **Self-hosted** (`IS_BILLING_ENABLED=false`): requires a valid Enterprise plan. - **Cloud** (billing enabled): metered by credits, mirroring the existing AI credit system. Priced on AWS SES cost ($0.10/1,000 outbound) × 3 margin = $0.30/1,000 (300 micro-credits/email). Pre-flight blocks sends when out of credits; each email is charged after SES accepts it, in the async send job — matching how AWS bills us (no refund on bounce). Enforcement is applied at every email group resolver, and denials surface as proper client errors through a dedicated GraphQL exception filter.	2026-07-02 15:14:49 +00:00
Thomas des Francs	d8cc81cb91	Improve billing settings UI (#22377) ... ## Summary - Refresh the settings billing subscription and credits cards with clearer status, usage, and action states. - Add the credit-package picker flow and route past-due/cancellation actions to billing management instead of credit modals. - Clean up related billing UI helpers and formatting. ## Screens ### regular <img width="1007" height="781" alt="image" src="https://github.com/user-attachments/assets/dc9c0c59-8cda-422a-a0d3-56292421a744" /> ### downgrading <img width="1049" height="818" alt="image" src="https://github.com/user-attachments/assets/0dc3dea8-5b55-4cf2-bc92-997cf6e9bebc" /> <img width="1048" height="901" alt="image" src="https://github.com/user-attachments/assets/fba805ad-f523-444b-93a0-2011b6b43443" /> ### Trialing without card <img width="1008" height="903" alt="image" src="https://github.com/user-attachments/assets/d5dd11b6-4c92-4102-ac22-ad1ad4e9fbfb" /> with card <img width="1008" height="806" alt="image" src="https://github.com/user-attachments/assets/0dbeb00e-890e-4448-94fe-0cc0ef411e8d" /> ### Past due & Unpaid <img width="1052" height="860" alt="Past due" src="https://github.com/user-attachments/assets/25ba53ef-6e74-4b4c-bfe1-d6c74e165917" /> <img width="1138" height="860" alt="Unpaid" src="https://github.com/user-attachments/assets/bb16fe65-84e4-40a7-8951-90b01030aded" /> --------- Co-authored-by: Etienne <45695613+etiennejouan@users.noreply.github.com>	2026-07-01 17:02:54 +00:00
Félix Malfait	b8a3399230	fix(billing): link billing emails to the workspace subdomain (#22401) ... ## Problem Billing and workspace-suspension emails hardcoded a `BILLING_SETTINGS_URL` constant pointing at `https://app.twenty.com/settings/billing`. A user in `myworkspace.twenty.com` therefore received a CTA that bounced through the central `app` domain instead of landing on their own workspace. Those cross-subdomain redirects are unreliable, so it's better to link straight to the workspace. The invite, password-reset and email-verification emails already do this correctly by building a workspace-specific URL server-side with `WorkspaceDomainsService.buildWorkspaceURL(...)`; the billing/suspension senders had the `workspace` entity in scope but never used it. ## Fix Build the billing settings URL server-side and pass it into the templates as a `link` prop, mirroring the existing pattern: - **Templates** now take a `link` prop instead of the hardcoded constant: `billing-trial-ending`, `billing-trial-converting`, `billing-subscription-renewing`, `warn-suspended-workspace`. - **`BillingReminderService`** and **`CleanerWorkspaceService`** build `buildWorkspaceURL({ workspace, pathname: getSettingsPath(SettingsPath.Billing) })` and thread it through. - Wired `WorkspaceDomainsModule` into both NestJS modules; deleted the now-unused `billing-settings-url.constant.ts`; updated the reminder unit test. This also fixes **self-hosted** deployments, which previously got the same wrong hardcoded `app.twenty.com` link. ### Intentionally unchanged - `clean-suspended-workspace` keeps its central-domain "start a new workspace" CTA — that workspace is already deleted, so its subdomain no longer resolves. - `password-update-notify` (not a billing email) still uses `getBaseUrl()`; the workspace entity isn't readily loaded there. Can be a follow-up. ## Testing Extended `billing-reminder.service.spec.ts` to assert the workspace-specific `link` is threaded into the email. Note: local `typecheck`/tests could not be run because the sandbox proxy repeatedly dropped `yarn install` mid-fetch; the diff was reviewed line-by-line and import paths verified against the actual `twenty-shared` exports and module wiring. CI will provide the authoritative check. https://claude.ai/code/session_01QsgNd4SWdcRkPFyrnCgj2b --- _Generated by [Claude Code](https://claude.ai/code/session_01QsgNd4SWdcRkPFyrnCgj2b)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22401?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-07-01 14:28:36 +00:00
martmull	e747bc3e42	Add backfill installation feature for pre-installed apps (#22199) ... ## After <img width="1070" height="514" alt="image" src="https://github.com/user-attachments/assets/9cbd2ff5-1678-4c2f-84da-074568f37c51" /> ## Summary Adds the ability to backfill application installations across all existing workspaces. This allows admins to retroactively install a pre-registered application on every active and suspended workspace through a background job, making the feature idempotent and non-blocking. ## Key Changes - **Backend Service**: Added `backfillApplicationOnAllWorkspaces()` method to `PreInstalledAppsService` that: - Validates the application registration exists - Iterates through all workspaces using `WorkspaceIteratorService` - Installs the app on each workspace - Swallows `APP_ALREADY_INSTALLED` errors for idempotency - Logs success/failure counts - **Background Job**: Created `BackfillApplicationInstallationJob` to process backfill requests asynchronously via the message queue - **GraphQL Mutation**: Added `backfillApplicationInstallation` mutation to `AdminPanelResolver` that: - Validates the application registration exists - Enqueues the background job - Returns immediately without blocking the request - **UI Components**: Enhanced `SettingsAdminApplicationRegistrationGeneralToggles` with: - New "Pre-install on new workspaces" toggle for the `isPreInstalled` flag - "Backfill on all workspaces" button with confirmation modal - Loading state and success/error snack bar feedback - **Data Model**: Added `isPreInstalled` field to `UpdateApplicationRegistrationPayload` input type - **Tests**: Added comprehensive unit tests for `PreInstalledAppsService.backfillApplicationOnAllWorkspaces()` covering: - Missing registration validation - Successful multi-workspace installation - Idempotent handling of already-installed errors - Proper error propagation for unexpected failures ## Implementation Details The backfill operation is designed to be: - **Idempotent**: Already-installed apps are skipped without error - **Non-blocking**: Runs as a background job via message queue - **Resilient**: Per-workspace failures don't block other installations - **Observable**: Logs aggregated success/failure counts for monitoring <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22199?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>	2026-06-26 16:21:27 +00:00
Félix Malfait	ea9e11581c	feat(billing): replace Stripe trial emails with fair, well-timed reminders (#22186) ... ## Why We currently rely on Stripe's automated trial-ending email. It misfires: the global "remind 7 days before trial ends" setting lands the reminder on **signup day** for the 7‑day no‑card trial, and the "your card will be charged" copy makes no sense for a trial with no card. This replaces it with our own honest, well‑timed, Twenty‑branded emails. ## 🔒 Safety — these emails are OFF by default Because these reach real customers, the whole feature is gated behind a kill‑switch that **defaults to `false`**: - **`BILLING_REMINDER_EMAILS_ENABLED` (default `false`)** — checked **both** at cron registration **and** on every job run (defense in depth), so the emails can never be sent inadvertently (not on deploy, not in staging, not via a stray trigger). They only go out once an operator explicitly opts in. - Also gated on `IS_BILLING_ENABLED` (cloud‑only; self‑hosters unaffected). - In non‑prod the email driver is typically `logger`, so even if enabled there, nothing is actually sent. A unit test asserts that with the switch off, **zero** emails are produced. ## What it does A daily cron (`0 8 * * *`) sends three honest, Twenty‑branded emails: | Plan | Email | When | |---|---|---| | No‑card trial (7d) | "Add a card to keep your data" | **1 day before** trial ends | | Card‑on‑file trial (30d) | Upcoming‑charge heads‑up (cancel in one click) | **7 days before** first charge | | Yearly subscription | Renewal reminder (no surprise) | **7 days before** each renewal | - **Monthly renewals get no reminder** (avoids noise) — only the first charge and annual renewals do. - Branches no‑card vs with‑card on the customer's payment‑method flag (with a trial‑duration fallback), so someone who adds a card mid‑trial correctly gets the charge heads‑up instead of the add‑a‑card one. - **Idempotent** per `(workspace, boundary date)` via workspace‑level user vars — yearly reminders re‑fire each period, but the daily cron never double‑sends. - Offsets are configurable via new `BILLING_*_REMINDER_DAYS_BEFORE` variables. Also **warms up the tone** of the existing suspended / deleted workspace emails (less robotic, fair, loss‑aversion framing) — these already act as the "come back or lose your data" win‑back, so no extra win‑back email was added. ## Rollout 1. Merge. 2. Disable Stripe's automated trial/renewal customer emails in the Stripe dashboard. 3. Review copy/timing, then set `BILLING_REMINDER_EMAILS_ENABLED=true` to turn the cron on. ## Notes for reviewers - **i18n:** new English strings render via Lingui's msgid fallback; translation catalogs are intentionally **not** included to keep the diff focused (the repo extracts translations via its standard periodic `lingui extract` sync — `main` already carries catalog drift). Diff is 18 code files. - **Recipients:** reminders go to all workspace members, consistent with the existing suspension emails. Happy to scope the charge‑related ones to billing admins if preferred. - **Follow‑ups discussed:** in‑app trial banner, loss‑aversion with real record counts, and failed‑payment dunning are the higher‑leverage conversion levers beyond this. ## Test plan - [x] `typecheck` (twenty-server, twenty-emails) - [x] oxlint type‑aware + oxfmt - [x] Unit tests: no‑card path, with‑card path, idempotency, yearly renewal, billing‑disabled, **kill‑switch off → no send** (6/6 green) - [ ] Manual: set the flag on a staging instance with `logger` driver and confirm the right email is logged at each boundary https://claude.ai/code/session_0147ujzHv1X4vzimf4iGbnT4 --- _Generated by [Claude Code](https://claude.ai/code/session_0147ujzHv1X4vzimf4iGbnT4)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22186?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-26 08:18:34 +02:00
Félix Malfait	94dbcc27a9	feat(billing): embed credit card form in the add-card trial-end modal (#22125) ... ## Context When a trialing workspace (trial without a credit card) clicks **Add Credit Card** from the "End trial period" banner or the AI-chat usage-limit banner, the modal currently redirects the browser to Stripe's hosted billing portal to collect the card. Since we already embed the Stripe Payment Element in onboarding, this brings the same in-app experience to the trial-end modal so the whole flow stays inside Twenty. ## Why the onboarding flow couldn't be reused as-is The onboarding embed (`createSubscriptionPaymentIntent` / `SubscriptionPaymentForm`) **creates a new subscription** with `payment_behavior: 'default_incomplete'`. In the trial-end case the customer **already has a trialing subscription**, so that path throws `BILLING_SUBSCRIPTION_INVALID`. The correct primitive here is a **SetupIntent** against the existing customer: collect + save the card, then end the trial. A standalone SetupIntent attaches the card to the customer but does **not** make it the default (the Stripe portal used to do that for us), so the trial-end invoice would have no payment method. The backend now backfills the customer default before charging. ## Changes **Backend** - `StripeCustomerService`: `createSetupIntent()` for an existing customer, and `ensureDefaultPaymentMethod()` which sets the customer default only when none is already set (won't clobber a portal-chosen default). - `BillingPortalWorkspaceService.createPaymentMethodSetupIntent()`: returns a SetupIntent client secret for the current non-canceled subscription's customer. - `BillingSubscriptionService.endTrialPeriod()`: ensures a default payment method before `trial_end: 'now'`. - New `createBillingPaymentMethodSetupIntent` mutation + `BillingSetupIntent` DTO; SDK schema snapshot synced. **Frontend** - `AddPaymentMethodForm`: Stripe Elements (`mode: 'setup'`), confirms with `redirect: 'if_required'` so the common card case stays in-app; 3DS still redirects and is finished by the existing `EndTrialAfterPaymentMethodEffect`. - `AddCreditCardModal`: hosts the embedded form. - Both trial-end banners (`InformationBannerEndTrialPeriod`, `AIChatNoMoreBillingCreditsBanner`) open the embedded modal instead of redirecting when no card is on file; the AI-chat path preserves its thread context in the 3DS return URL. ## Flow 1. User clicks **Add Credit Card** → embedded modal opens. 2. Card entered → `createBillingPaymentMethodSetupIntent` → `confirmSetup({ redirect: 'if_required' })`. 3. Non-3DS: confirms inline → `endSubscriptionTrialPeriod` → subscription active, no redirect. 4. 3DS: redirects to `?startSubscriptionAfterPaymentMethod=true` → existing effect finishes activation. 5. Self-hosted instances without a Stripe publishable key fall back to the existing portal redirect (the form renders an unavailable state). ## Notes for reviewers - The metadata GraphQL types were regenerated by hand (codegen needs a live `/metadata` server, which wasn't available in the authoring environment); a `graphql:generate --configuration=metadata` run against a live backend should be a no-op. - Local `typecheck`/`lint` could not be run in the authoring environment (dependency install was blocked); relying on CI to validate. - Scope is intentionally limited to the two trial-end banner modals. The Settings → Billing "update payment method" link still uses the Stripe portal. https://claude.ai/code/session_01VU7SfrSgaYWr2AhVL8DMfu --- _Generated by [Claude Code](https://claude.ai/code/session_01VU7SfrSgaYWr2AhVL8DMfu)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22125?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-25 04:49:31 +02:00
Raphaël Bosi	6b460da622	Add backend primitive to credit a workspace's billing balance (#22094) ... Adds `BillingCreditService.creditWorkspaceBalance({ workspaceId, amountMicro })`, an internal, server-side primitive to grant spendable resource credits to a workspace. This is the backend foundation for awarding free credits during the new onboarding steps; there was no existing way to add credits to a workspace. What it does: - Increments `billingCustomer.creditBalanceMicro` atomically (workspace-scoped), then flushes the Redis available-credits cache so the credit is immediately spendable, not just shown in the gauge. - No-ops when billing is disabled or no billing customer exists; rejects non-positive/non-finite amounts. - Pure primitive with no GraphQL/REST surface; the caller owns idempotency. Notes for reviewers: - Credits use the existing `RESOURCE_CREDIT` currency (micro units, 1 display credit = 1,000,000 micro). - The credited balance is overwritten by the rollover job at the next billing-period renewal, so it is not guaranteed to persist across periods (intentional for onboarding bonuses). <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22094?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-24 17:28:24 +02:00
Etienne	90acecfbd9	feat(billing): invoice on seat increase (#22083) ... ## Context Two billing improvements around workspace seat changes: 1. **Delay subscription quantity updates.** Every workspace member create/delete/destroy event used to enqueue an `UpdateSubscriptionQuantityJob` immediately. 2. **Invoice immediately when seats increase.** Seat increases previously used `create_prorations`, which defers the charge to the next billing cycle. We now bill the proration right away on increases, while keeping deferred prorations on decreases / no-ops. ## Changes ### Job delaying - `BillingWorkspaceMemberListener` now enqueues the job with the per-workspace id and a 24h delay. Re-adds within the window coalesce to a single delayed run per workspace, collapsing bursts of member changes into one Stripe update. ### Proration behavior - `computeSubscriptionUpdateOptions` now accepts an optional `{ currentSeats }` context. For `SEATS` updates it returns `always_invoice` when `newSeats > currentSeats`, otherwise `create_prorations` (decrease or unchanged). - `BillingSubscriptionUpdateService` passes `currentSeats: licensedItem.quantity` so the decision is based on the actual current subscription quantity. ## Tests - `compute-subscription-update-options.util.spec.ts`: added cases for seat increase (`always_invoice`), decrease (`create_prorations`), and unchanged (`create_prorations`). - `billing-subscription-update.service.spec.ts`: updated expectations to `always_invoice` for the seat-increase paths. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22083?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-24 14:31:15 +00:00
Félix Malfait	adf6eb572b	feat(billing): embed Stripe Payment Element in onboarding (#21759) ... ## What & why Replaces the hosted Stripe Checkout redirect on the onboarding "Choose your plan" step (credit-card trial) with an inline Stripe **Payment Element**, so users never leave the app to enter card details. ## How it works - **Frontend:** a deferred `<Elements mode="setup">` renders the Payment Element, themed via the Appearance API. On Continue: `elements.submit()` → `checkoutSession` mutation creates the trialing subscription server-side and returns its pending SetupIntent `clientSecret` → `stripe.confirmSetup()` confirms the card (handling 3DS) → redirect to the existing `/plan-required/payment-success`. - **Backend:** new `BILLING_STRIPE_PUBLISHABLE_KEY` config var exposed via `/client-config`; the card path creates the subscription with `payment_behavior: default_incomplete` + a free trial (so Stripe attaches a `pending_setup_intent`) and returns its client secret. The hosted-Checkout code path is removed. - The **no-credit-card** trial path is unchanged. - Billing address collection is **disabled** in the Payment Element to reduce friction; `automatic_tax` is correspondingly disabled (tax needs an address — collect it later, e.g. at conversion / via the billing portal). ## Required before this works 1. Set `BILLING_STRIPE_PUBLISHABLE_KEY` (`pk_…`) on the server (infra change pending). 2. Run `nx run twenty-front:graphql:generate --configuration=metadata` against a server exposing the updated schema (see inline note on the hand-authored document). 3. Verify in Stripe test mode: happy path, 3DS (`4000 0025 0000 3155`), a decline. ## Verified typecheck (front + server), oxlint + oxfmt clean, `client-config.service.spec` passing. Not run here: the app end-to-end / Stripe test mode and `graphql:generate` (no server/DB in the dev container). I've left self-review comments inline flagging cleanup opportunities plus a couple of architectural/tech-debt items. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01TxCfinXq7abSrbF7aTw2cA --- _Generated by [Claude Code](https://claude.ai/code/session_01TxCfinXq7abSrbF7aTw2cA)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21759?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-06-19 11:40:55 +02:00
nitin	640a8e6ca6	Add post-call recording ingestion and billing (#21758) ... ## Summary - Add post-call Recall recording ingestion for transcripts, audio, and video - Request/retrieve async transcripts and reconcile stale pending transcript markers - Complete call recordings atomically once all artifacts and billable timestamps are available - Charge `CALL_RECORDING` usage once per completed recording based on recording duration - Add Recall recording/media API helpers, transcript marker utilities, and audio/video field identifiers - Update generated metadata/SDK files and billing usage operation support - Add unit coverage for ingestion, completion, charging, Recall API behavior, and reconciliation flows <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21758?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-18 14:01:18 +05:30
Etienne	d99e479be8	feat(billing) - facilitate top up in ai chat (#21645) ... Today, when a trialing user hits their AI usage cap inside the Ask AI chat, ending the trial bounces them to the Stripe billing portal (and, for card-less users, loses their place in the conversation). This PR makes activating a paid plan / topping up credits feel seamless from within the chat: Trial users with a card on file activate their subscription in place, without leaving the app. Trial users without a card are sent to the Stripe payment-method portal and, on return, the trial is ended automatically and they're dropped back into the exact Ask AI thread they came from. Credit-exhaustion and trial banners now reflect whether a payment method exists (Add Credit Card vs Subscribe Now / End Trial Period) and upgrade inline via a confirmation modal instead of redirecting to Settings. Uploading Screen Recording 2026-06-16 at 07.51.12.mov… https://github.com/user-attachments/assets/4ea77273-da63-4b32-b6f1-5ac9e9560651 <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21645?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-17 16:20:11 +00:00
Charles Bochet	9bb98fa5b5	fix(billing): don't crash when workspace has no active subscription (#21510) ... ## Problem Sentry (high severity, SLA-breaching): `Billing Subscription Not Found: No active subscription found for workspace …` The `billingSubscription` workspace-cache provider (`WorkspaceBillingSubscriptionCacheService.computeForCache`) called `getCurrentBillingSubscriptionOrThrow`. For a workspace whose subscription is fully canceled, `getCurrentBillingSubscription` filters out `Canceled` and returns `undefined`, so the provider **threw** `BILLING_SUBSCRIPTION_NOT_FOUND`. That cache key is read on every usage-recording path: - workflow execution (`WorkflowExecutorWorkspaceService.sendWorkflowNodeRunEvent`) - AI usage (`AiBillingService`) - logic-function execution (`LogicFunctionExecutorService`) - app charges (`AppBillingService`) - the gate `BillingUsageService.canFeatureBeUsed` / `hasAvailableCredits` / `decrementAvailableCreditsInCache` - the cancellation webhook (`invalidateAndRecompute('billingSubscription')`) So any of these throws an unhandled exception for a no-active-subscription workspace. The intent was clearly to tolerate this state — `canFeatureBeUsed` already guards with `isDefined(billingSubscription)` and the workflow runner logs *"there is no subscription for this workspace"* — but the throwing provider made those guards unreachable. ## Fix - `computeForCache` now returns `FlatBillingSubscription | null` via the non-throwing `getCurrentBillingSubscription`, and the cache type allows `null`. - Every consumer guards the absent case (`isDefined` / optional chaining) and no-ops: usage events still emit with an undefined `periodStart`, credits aren't decremented, `hasAvailableCredits` returns `false`. - `getCurrentBillingSubscriptionOrThrow` is **left untouched** for the many callers (resolver, subscription-update, etc.) that genuinely require a subscription. ## Test Adds `workspace-billing-subscription-cache.service.spec.ts`: the provider returns `null` when there's no active subscription (regression) and the flattened subscription when one exists. All 142 tests across the billing / ai-billing / workflow-executor suites pass; `oxlint --type-aware` and `oxfmt` are clean. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21510?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-12 22:47:44 +02:00
Etienne	a6fcbf58e4	fix(billing) - enable upgrade if invoice already paid (#21450) ... Had an issue concerning a user with credits, then invoice automatically paid. Upgrade failed	2026-06-11 12:45:01 +00:00
Etienne	27db8bbae4	fixes - remove billing cancellation at trial end + disable ai chat if suspended (#21261) ... - Remove billing cancelation if trial is ended (subscription activated) - Disable AI Chat use if workspace suspended	2026-06-05 15:34:12 +00:00
Paul Rastoin	3d49642d12	[AUDIT] Run knip over twenty-server (#21159) ... # Introduction Run [knip](https://knip.dev/) over twenty-server Used config: ```json { "$schema": "https://unpkg.com/knip@5/schema.json", "workspaces": { "packages/twenty-server": { "entry": [ "src/main.ts", "src/command/command.ts", "src/queue-worker/queue-worker.ts", "src/database/scripts/setup-db.ts", "src/database/scripts/truncate-db.ts", "src/database/clickHouse/migrations/run-migrations.ts", "src/database/clickHouse/seeds/run-seeds.ts", "src/instrument.ts", "lingui.config.ts", "test/integration/graphql/codegen/index.ts", "test/integration/utils/setup-test.ts", "test/integration/utils/teardown-test.ts", "scripts/**/*.ts", "**/*.spec.ts", "**/*.integration-spec.ts" ], "project": ["src/**/*.ts", "test/**/*.ts", "scripts/**/*.ts"], "ignore": [ "src/database/typeorm/**/migrations/**", "src/database/typeorm/**/*.entity.ts", "**/*.workspace-entity.ts", "**/logic-function-resource/constants/seed-project/**" ], "ignoreDependencies": ["@types/psl", "@types/aws-lambda"], "ignoreBinaries": ["nest", "lingui", "typeorm"] } } } ```	2026-06-04 10:05:22 +00:00
Etienne	381ca32055	Billing - Fix credit upgrade invoice error (#21097) ... In createImmediateUpgradeInvoice, the invoice is finalized with auto_advance: true, which causes Stripe to automatically attempt payment asynchronously. Then the explicit stripe.invoices.pay(invoice.id) call races against that auto-payment — if Stripe already paid it, this throws "Invoice is already paid". The fix is to finalize with auto_advance: false and keep the explicit pay call	2026-06-01 13:55:06 +00:00
Félix Malfait	4797d2f270	feat(twenty-orm): introduce WorkspaceScopedRepository for core/metadata workspace-scoped entities (#20953) ... ## Summary Adds a third tenancy enforcement layer for entities that live in shared schemas (`core`, `metadata`) and carry a `workspaceId` column — previously the only safeguard at this layer was developer discipline (remembering to put `workspaceId` in every WHERE clause). ### The three layers, after this PR | Layer | Scope | How it's enforced | |---|---|---| | 1. Workspace data | per-workspace schema (companies, people, custom objects) | `twentyORMManager.getRepository(workspace, E)` — physical isolation (own data source) | | 2. Metadata | shared `metadata` schema (objectMetadata, fieldMetadata, views, roles…) | Flat-entity-maps cache — workspace-scoped in-memory map, lookups by id within it | | 3. Core (new) | shared `core` schema (agent threads/turns/messages, app tokens, etc.) | `WorkspaceScopedRepository<T>` — `workspaceId` is a required positional argument on every read/write | ## What's in the PR ### The wrapper (`packages/twenty-server/src/engine/twenty-orm/workspace-scoped-repository/`) - `WorkspaceScopedRepository<T extends WorkspaceScopedEntity>` — wraps a TypeORM `Repository<T>`, requires `workspaceId` on every `find`/`findOne`/`findOneOrFail`/`update`/`delete`/`softDelete`/`insert`/`save`/`count` call, merging it into the WHERE or stamping it on the entity. `createQueryBuilder` is an explicit escape hatch (caller scopes manually). - Provided via Nest DI with `@InjectWorkspaceScopedRepository(EntityClass)` and the `provideWorkspaceScopedRepository(EntityClass)` provider factory. - 19 unit tests cover the merge behavior, override-on-conflict, and the array-where (OR) case. ### Lint enforcement (`packages/twenty-oxlint-rules/rules/prefer-workspace-scoped-repository.ts`) - New `twenty/prefer-workspace-scoped-repository` rule (level: **error**). - Blacklist of entity names: raw `@InjectRepository(E)` is rejected if `E` is on the list. - Initial list: `AgentTurnEntity`, `AgentMessageEntity`, `AgentMessagePartEntity`, `AgentChatThreadEntity`, `AgentTurnEvaluationEntity`, `AgentEntity`. - Designed to grow over time as more consumers are migrated. - 5 rule tests. ### Migration in this PR All consumers of the six blacklisted entities, including: - AI agent / chat / monitor resolvers, services, and jobs - `AgentService`, `AiAgentRoleService`, `AiAgentWorkflowAction`, `ApplicationService`, `WorkspaceFlatAgentMapCacheService` - Admin-panel chat (migrated where the lookup is workspace-known; one documented `eslint-disable` on the threadId-discovery lookup that necessarily precedes the `allowImpersonation` permission check) - `AiAgentRoleService` unit spec updated to mock the scoped wrapper ## Future work (deliberately not in this PR) A standalone audit identified ~14 additional `core`/`metadata` entities with `workspaceId` that currently use raw `@InjectRepository` and could be added to the blacklist. Notable candidates: `UserWorkspaceEntity` (42 sites), `AppTokenEntity` (10), `FileEntity` (7), `BillingCustomerEntity`/`BillingSubscriptionEntity` (~22 combined). Each should be its own PR — the migration is mechanical but the surface is wide. ## Test plan - [x] `npx nx typecheck twenty-server` — clean - [x] `npx nx lint twenty-server` — 0 warnings, 0 errors - [x] `npx jest workspace-scoped-repository` — 19/19 pass - [x] `npx nx test twenty-oxlint-rules` — 215/215 pass - [x] `npx jest src/engine/metadata-modules/ai` — 44/44 pass - [ ] Manual smoke: end-to-end AI agent chat send/receive (reviewer) - [ ] Manual smoke: AI agent monitor — list turns, run evaluation (reviewer) - [ ] Manual smoke: admin-panel chat thread inspection (reviewer)	2026-05-27 18:52:53 +02:00
Etienne	50c8834e21	fix(billing) - skip redundant cap writes (#20882) ... fixes https://sonarly.com/issue/40207	2026-05-25 12:03:18 +00:00
Etienne	0edd8d400c	fix(billing) - fix orphaned stripe subs (#20814) ... Fix sentry issues https://twenty-v7.sentry.io/issues/7203797925/?environment=prod&project=4507072499810304&query=is%3Aunresolved%20assigned%3Ame&referrer=issue-stream An orphaned sub is a not "canceled" stripe sub with no matching workspace - Clean all orphaned sub (script not included in this PR) - Ensure to soft delete > cancel stripe sub > check for not active sub > hard delete in every workspace deletion flow Bonus : - Remove dead code - Update doc on RLS (to improve AI chat knowledge)	2026-05-21 17:02:54 +00:00
Etienne	fc74938d7b	fix(billing) - query timeout (#20669) ... Sonarly context : https://sonarly.com/issue/33412 Sentry issue : https://twenty-v7.sentry.io/issues/7454613767/?project=4507072499810304	2026-05-18 12:29:47 +00:00
Etienne	fcd2d586ee	chore(billing) - remove feature flag (#20531) ... - remove feature flag - remove old enforce cap usage logic	2026-05-13 18:52:29 +02:00
Etienne	aecfe699f4	feat(ai-chat) - Stop ai thinking if credits exhausted (#20526) ... Billing is now decremented per-step, not per-turn. The onStepFinish callback in chat-execution.service.ts calls a new decrementAndCheckAvailableCredits method on each model step, so Redis is debited incrementally as the agent runs rather than all at once at the end. Credit exhaustion stops the stream mid-run. When a step depletes the remaining credits, a hasNoMoreAvailableCredits flag is set and passed into the stopWhen predicate of streamText, causing the agent to halt before starting the next step. A new credits-exhausted event is introduced. After the stream drains and the response is persisted, if credits ran out the job publishes a dedicated credits-exhausted event to the frontend instead of the normal message-persisted event. The frontend handles this new event. useAgentChatSubscription has a new credits-exhausted case that sets a BILLING_CREDITS_EXHAUSTED-coded error on the atom, closes the writer, and stops the streaming state — triggering the existing AiChatCreditsExhaustedMessage UI.	2026-05-13 15:09:08 +00:00
Paul Rastoin	a159a68e2c	[twenty-server] no floating promises lint rule (#20499) ... ## Introduction That's an audit + RFC ## Fire-and-forget (`void`) -- Intentional, correct These are telemetry, metrics, and audit logging in hot paths or non-critical contexts. `void` is the right choice. | File | What was voided | |---|---| | `sign-in-up.service.ts` | `metricsService.incrementCounter` (sign-up metric) + `auditService.insertWorkspaceEvent` (workspace created) | | `use-graphql-error-handler.hook.ts` | 5x `metricsService.incrementCounter` (GraphQL operation metrics) | | `bullmq.driver.ts` | 2x `metricsService.incrementCounter` (job completed/failed metrics) | | `call-webhook.job.ts` | 2x `auditService.insertWorkspaceEvent` + 1x `metricsService.incrementCounter` | | `custom-domain-manager.service.ts` | `analytics.insertWorkspaceEvent` (domain activation event) | | `logic-function-executor.service.ts` | `auditService.insertWorkspaceEvent` (function execution) | | `workflow-runner.workspace-service.ts` | `metricsService.incrementCounter` (throttle metric) | | `cleaner.workspace-service.ts` | `metricsService.incrementCounter` (deleted workspace metric) | | `stream-agent-chat.job.ts` | Detached IIFE for streaming chunks (intentional concurrent pipeline) | | `workspace-auth-context.middleware.ts` | `withWorkspaceAuthContext(...)` (AsyncLocalStorage, returns void anyway) | ## Top-level script entry points (`void bootstrap()`) These are module-level calls where the promise has no consumer. `void` makes the lint rule happy and documents the intent. | File | What changed | |---|---| | `main.ts` | `void bootstrap()` | | `command.ts` | `void bootstrap()` | | `queue-worker.ts` | `void bootstrap()` | | `truncate-db.ts` | `void dropSchemasSequentially()` | | `codegen/index.ts` | `void generateTests(forceArg)` | ## Now properly awaited -- Real bug fixes These were floating promises that could silently fail, lose data, or cause race conditions. | File | What was fixed | |---|---| | `billing-sync-plans-data.command.ts` | `meters.map(async ...)` wrapped in `Promise.all` -- was returning before upserts finished | | `cache-storage.service.ts` | `setAdd` and `setPop` had `.then()` chains that weren't returned/awaited | | `create-audit-log-from-internal-event.ts` | 4x `auditService.createObjectEvent` now awaited inside a job | | `cleaner.workspace-service.ts` | 2x `emailService.send(...)` now awaited -- emails could silently fail | | `agent-async-executor.service.ts` | `calculateAndBillUsage` + `billNativeWebSearchUsage` in `finally` block now awaited | | `repair-tool-call.util.ts` | `calculateAndBillUsage` now awaited | | `agent-title-generation.service.ts` | `calculateAndBillUsage` now awaited | | `chat-execution.service.ts` | `billNativeWebSearchUsage` now awaited | | `ai-generate-text.controller.ts` | `calculateAndBillUsage` in `finally` block now awaited | | `agent-turn.resolver.ts` | `messageQueueService.add(...)` now awaited | | `command.ts` | `app.close()` now awaited (was exiting before graceful shutdown) | | `i18n.service.ts` | `loadTranslations()` in `onModuleInit` now awaited | | `workspace-query-hook.explorer.ts` | `explore()` in `onModuleInit` now awaited | | `message-queue.explorer.ts` | `handleProcessorGroupCollection` in `onModuleInit` now awaited | | `ai-billing.service.spec.ts` | Test now properly `await`s the async call | | `messaging-messages-import.service.spec.ts` | `expect(...)` now properly `await`ed for async assertion | | `archive.finalize()` (3 files) | Voided -- promise resolution already handled by `pipeline()` / `on('end')` | ## Impersonation & security audit trail -- Upgraded from `void` to `await` These were previously fire-and-forget but are security/compliance-critical events that must be reliably persisted. | File | What was fixed | |---|---| | `impersonation.service.ts` | 4x `auditService.insertWorkspaceEvent` now awaited (impersonation attempt, token generation attempt/success/failure) | | `auth.resolver.ts` | 5x `auditService.insertWorkspaceEvent` now awaited (impersonation token exchange attempt/success/failure at server and workspace levels) | | `auth.service.ts` | 2x `analytics.insertWorkspaceEvent` now awaited (impersonation attempted/issued) | ## Billing audit -- Upgraded from `void` to `await` Payment events should be reliably persisted for financial/compliance reporting. | File | What was fixed | |---|---| | `billing-webhook-invoice.service.ts` | `auditService.insertWorkspaceEvent(PAYMENT_RECEIVED_EVENT)` now awaited inside Stripe webhook handler | ## Fire-and-forget with proper error handling -- Upgraded from bare `void` These remain non-blocking but now catch and log errors instead of risking unhandled rejections. | File | What was fixed | |---|---| | `logic-function-executor.service.ts` | `applicationLogsService.writeLogs` now uses `.catch()` instead of bare `void` -- user-facing logs should surface errors | ## Systemic infrastructure fixes | File | What was fixed | |---|---| | `metrics.service.ts` | `incrementCounter`: Redis cache write (`metricsCacheService.updateCounter`) now uses `.catch()` internally instead of raw `await` -- prevents unhandled rejections across all `void metricsService.incrementCounter(...)` call sites when Redis is unhealthy | | `audit.service.ts` | `preventIfDisabled`: made properly `async` with `await` and consistent `Promise<{ success: boolean }>` return type. Removed broken `catch` that returned an `AuditException` as a value (wrong constructor args, unreachable dead code). Removed unused `AuditException` import | ## Fixed in this session (beyond original PR) | File | What changed | |---|---| | `telemetry.listener.ts` | Removed misleading `Promise.all` + `void` combo; replaced with simple `for...of` + `void` | | `message-queue.explorer.ts` | Changed from `void` to `await` so startup crashes on registration failure |	2026-05-13 10:08:42 +00:00
Etienne	9fc5be1c4c	Billing - Migrate from Stripe metering (#20298) ... **Overall strategy** **1. Introduce “Billing V2” behind a workspace flag** Gate the new model with FeatureFlagKey.IS_BILLING_V2_ENABLED so existing workspaces stay on the old behavior until they’re migrated or explicitly on V2. **2. Replace workflow metered SKUs with a resource-credit product** Conceptually, billable “workflow execution” usage is not the primary subscription line item anymore. Add a RESOURCE_CREDIT product (and keep WORKFLOW_NODE_EXECUTION as deprecated for the transition). Usage and limits are expressed through credit buckets (e.g. price metadata like credit_amount), so one product can represent pooled credits instead of a narrow workflow-only meter. **3. Migrate subscriptions in two layers** Schema/catalog: persist extra price metadata (instance upgrade) so the server knows credit amounts and can match Stripe prices to the new model. Per workspace: the registered workspace command upgrade:2-2:migrate-to-billing-v2 finds subscriptions that still have WORKFLOW_NODE_EXECUTION, swaps those items to the right RESOURCE_CREDIT prices (using existing Stripe schedule + BillingSubscriptionUpdateService stack), then treats the workspace as V2 (flag). Workspaces without that legacy item or without a subscription are skipped. **4. Unify subscription lifecycle + usage on the server** **5. Refresh the product surface in Settings** Test : - [x] Subscribe v1 + Update subscribe + Migrate - [x] Subscribe v2 + Update subscribe	2026-05-07 15:42:11 +00:00
Félix Malfait	842e679cc6	fix(billing): gate AI credit-cap at entry points instead of workflow executor (#20096) ... ## Background The 2026-04-26 incident saw 716M Sonnet 4.6 tokens consumed in a single trial workspace. Two causes: failed agent executions weren't billed (addressed by #20065) and the credit-cap gate had been removed from `WorkflowExecutorWorkspaceService.executeStep` in #19904, leaving no enforcement point at all. ## Why not just revert #19904 #19904 was right that gating at the workflow executor is too coarse. When one user exhausted a workspace's credits via chat, *all* workflows hard-failed mid-run — including cheap DB/CRUD/branch automations costing essentially nothing. Reverting would re-introduce that cliff. ## New design: gate at the AI entry points The chat resolver already gates this way (`agent-chat.resolver.ts:137-148`). This PR replicates the same pattern at every other point where the workspace can incur real AI cost: - `executeAgent` in `agent-async-executor.service.ts` - the REST handler in `ai-generate-text.controller.ts` - `generateThreadTitle` in `agent-title-generation.service.ts` In each, after auth/validation: skip if `IS_BILLING_ENABLED` is false; otherwise call `BillingService.canBillMeteredProduct(workspaceId, BillingProductKey.WORKFLOW_NODE_EXECUTION)`; on `false`, throw `BillingException(BILLING_CREDITS_EXHAUSTED)`. No new method, no new exception code, no new product key. This matches industry convention (Lovable/Replit also gate at the expensive-operation boundary, not at every cheap step). ## Deliberately not gated - `WorkflowExecutorWorkspaceService.executeStep` — the design choice is now intentional, so the #19904 TODO is replaced by a one-line absolute-behavior comment explaining why the gate isn't here. Cheap workflow steps (DB CRUD, branching, action steps) are not gated, so a chat-driven cap exhaustion does not block non-AI automations. - `repair-tool-call.util` — repair is a sub-call inside an already-gated AI flow. If the parent is gated, repair will naturally not run. Adding a gate here adds complexity without value. ## Net effect A workspace that exhausts credits via chat or AI agent stops making AI calls. Its non-AI workflows continue running normally. A workflow with both AI and non-AI steps fails at the AI step with `BILLING_CREDITS_EXHAUSTED`, but downstream non-AI steps that don't depend on the AI output still run. ## Conflicts This PR overlaps with three other in-flight PRs in the same files. None of them touch the gate logic; rebasing on top of any of them is trivial: - #20065 (agent-async-executor): adds `workspaceId` to `executeAgent` args and bills in `finally`. The gate at the top of `executeAgent` from this PR sits naturally above that. - #20066 (REST controller): adds usage billing to the controller. - #20067 (title gen): adds usage billing to title generation and tool-call repair. Recommend landing #20065/#20066/#20067 first; this PR rebases trivially on top. ## Tests Out of scope per the PR series convention. The existing chat-resolver gate isn't unit-tested either; this PR follows the same precedent. Follow-up: add integration coverage that exercises a workspace at `hasReachedCurrentPeriodCap=true` against each of the three new gates plus the pre-existing chat-resolver gate. ## Future follow-ups - Per-user soft cap inside a workspace (the Lovable Business-tier pattern), so one user can't exhaust the workspace's cap. - Pre-flight cost estimate so the user sees an "approaching cap" warning before the hard stop. - Rename `BillingProductKey.WORKFLOW_NODE_EXECUTION` — the name predates this design choice and is misleading now that it gates AI entry points rather than workflow nodes. ## Test plan - [ ] Trigger a workspace into `hasReachedCurrentPeriodCap=true`. - [ ] Send a chat message — expect failure with `BILLING_CREDITS_EXHAUSTED`. - [ ] Run a workflow whose only AI step is an `ai-agent` action — expect that step to fail with `BILLING_CREDITS_EXHAUSTED`, downstream non-AI steps still run. - [ ] POST to `/rest/ai/generate-text` — expect `BILLING_CREDITS_EXHAUSTED`. - [ ] Create a new chat thread (which kicks off `generateThreadTitle`) — expect `BILLING_CREDITS_EXHAUSTED`. - [ ] Run a workflow with no AI step (only DB CRUD/branching/actions) — expect it to run unaffected. --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 18:48:06 +02:00
Etienne	fbaea0639a	Billing - optimize usageEvent CH table (#20019) ... - Update usageEvent clickhouse table, partitioning, indexing and projection (auto materialized view) to optimize credit usage queries - Add caching for available credits and billing subscription To do in next PR: deprecate enforceCapUsage cron. Bonus : real-time on billingSubscription	2026-04-28 14:06:49 +00:00
Félix Malfait	4f938aa097	feat(app): infrastructure for pre-installed apps (#19973) ... **PR 1 of 2.** Follow-up PR ships the Exa app, sets it as a default pre-installed app, and removes the current `WebSearchTool` / `WebSearchService` / `ExaDriver`. This PR adds the plumbing; no user-visible change yet. ## Summary - Server admins can declare a list of npm app packages to auto-install on every new workspace and backfill onto existing workspaces via CLI. - Server-level secrets (like Exa's API key) live on the `ApplicationRegistration` (one row per server, encrypted) and are injected into logic function execution env at runtime. No more per-workspace storage of global secrets. - A generic `POST /app/billing/charge` endpoint lets app logic functions emit workspace usage events for metered features. Exa uses it in PR 2; future apps (call recorder, etc.) reuse it. - `LogicFunctionToolProvider` tool name prefix changes `logic_function_` → `app_`. Shorter, accurate (they come from installed apps). ## What's in this PR **Logic function executor — server-level variables** - `LogicFunctionExecutorService.getExecutionEnvVariables` now resolves env vars in the order: hardcoded defaults → `ApplicationRegistrationVariable[]` (server-level) → `ApplicationVariable[]` (workspace-level override). The manifest `serverVariables` schema has existed; this closes the loop. **Config** - `PRE_INSTALLED_APPS` — comma-separated list of npm packages. Default: empty. **\`PreInstalledAppsService\`** (new module) - \`onApplicationBootstrap()\` — fetches each package's manifest from the app registry CDN, upserts an \`ApplicationRegistration\`, and seeds declared \`serverVariables\` from matching env vars (e.g. \`EXA_API_KEY\` env → encrypted registration variable). - \`installOnWorkspace(workspaceId)\` — installs all pre-installed apps on a single workspace. Tolerates per-app failures. **Auto-install on new workspace activation** - \`WorkspaceService.prefillCreatedWorkspaceRecords\` invokes \`installOnWorkspace\` after prefilling standard records. Non-blocking on failure. **Backfill CLI command** - \`install-pre-installed-apps\` — iterates active and suspended workspaces, installs pre-installed apps that aren't yet installed. Idempotent. Run after changing \`PRE_INSTALLED_APPS\`. **App billing endpoint** - \`POST /app/billing/charge\`. Authenticated via \`APPLICATION_ACCESS\` token (already injected into logic function execution env as \`DEFAULT_APP_ACCESS_TOKEN\`). Body: \`{ creditsUsedMicro, quantity, unit, operationType, resourceContext? }\`. Emits \`USAGE_RECORDED\` with \`applicationId\` as \`resourceId\`. Generic — reusable by any app. **Tool name prefix** - \`LogicFunctionToolProvider.buildLogicFunctionToolName\` now produces \`app_<name>\` instead of \`logic_function_<name>\`. Only affects tools sourced from logic functions; other tool providers unchanged. ## Stats - 16 files, +501 / −2 - 7 new files (1 command, 1 service × 2, 1 controller, 1 DTO, 2 modules) - Typecheck: 7 pre-existing errors, zero new - Prettier clean ## Behavior deltas - **\`PRE_INSTALLED_APPS\` default = empty**: existing servers see no change on merge. - **\`ApplicationRegistrationVariable\` is now read by the executor**: apps that were using manifest \`serverVariables\` but expecting them to be ignored by the executor will now see them injected. No apps ship with \`isTool: true\` logic functions today, so this is latent — first consumer is Exa in PR 2. - **Tool prefix**: currently no logic-function tools are named \`logic_function_*\` in any production flow. The prefix change affects only future tools emitted by \`LogicFunctionToolProvider\`. ## Risks - **CDN unavailability at startup**: if the app registry CDN is down, \`ensureRegistrationsExist\` logs warnings but doesn't block server start. Installation on new workspaces during this window will find no registrations and log a non-blocking error. Backfill command can retry after CDN recovers. - **Cold-start overhead**: \`ensureRegistrationsExist\` is called once per process on bootstrap. Current configurable default is empty, so zero overhead. When an admin sets \`PRE_INSTALLED_APPS\`, they accept one HTTP call per package at boot. - **Server-level variables flow**: \`ApplicationRegistrationVariable.encryptedValue\` is shared by all workspaces of a server. Appropriate for a single-tenant Exa key. Not appropriate for per-tenant keys — those go in workspace-level \`ApplicationVariable\` and override. ## Test plan - [ ] \`npx nx typecheck twenty-server\` passes (verified: 7 pre-existing unrelated errors, zero new) - [ ] Set \`PRE_INSTALLED_APPS=@twenty-apps/hello-world\` (or any real npm-published app), \`HELLO_WORLD_API_KEY=xxx\`, restart server: \`ApplicationRegistration\` row is upserted, \`ApplicationRegistrationVariable\` for HELLO_WORLD_API_KEY is populated (encrypted). - [ ] Create a new workspace: the app is auto-installed, \`ApplicationEntity\` row created, \`LogicFunctionEntity\` rows created. - [ ] Existing workspace: run \`yarn nx run twenty-server:command install-pre-installed-apps\`: apps install across all workspaces, idempotent on re-run. - [ ] Trigger a logic function that reads \`process.env.HELLO_WORLD_API_KEY\`: value resolves from the server-level \`ApplicationRegistrationVariable\`. - [ ] Log a charge from the handler: \`POST /app/billing/charge\` with \`Authorization: Bearer \$DEFAULT_APP_ACCESS_TOKEN\` body \`{creditsUsedMicro: 1000, quantity: 1, unit: "INVOCATION", operationType: "WEB_SEARCH"}\` → returns \`{success: true}\`, \`USAGE_RECORDED\` event emitted with correct \`resourceId=applicationId\`. - [ ] Tool name generated by \`LogicFunctionToolProvider\` starts with \`app_\`. ## What's NOT in this PR (PR 2 scope) - The Exa app itself (\`packages/twenty-apps/...\` directory) - Removing \`WebSearchTool\`, \`WebSearchService\`, \`ExaDriver\`, \`web-search\` module - Removing \`WEB_SEARCH_DRIVER\` config var - Removing the current \`exa_web_search\` entry in \`ActionToolProvider\` - Chat preload list updated to \`app_exa_web_search\` - Frontend \`getToolDisplayMessage\` branch for \`app_exa_web_search\` - Setting \`PRE_INSTALLED_APPS\` default to include \`@twenty-apps/exa\` --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-23 21:59:00 +02:00
Etienne	e68842c268	Billing - fixes (#19867) ... - Uniformize credit formating : In UI, 1$=1credit. In BE 1 UI credit = 1_000_000 BE "crédits" - Add crédit rollover information + Link to documentation + Documentation update <img width="291" height="317" alt="Screenshot 2026-04-17 at 18 22 59" src="https://github.com/user-attachments/assets/2519fb9f-159d-4c85-95f4-a6e005a8a1a3" /> <img width="848" height="763" alt="Screenshot 2026-04-17 at 14 12 20" src="https://github.com/user-attachments/assets/a3cc0874-f275-49ea-819f-305ec314bdfe" /> <img width="797" height="757" alt="Screenshot 2026-04-17 at 14 12 13" src="https://github.com/user-attachments/assets/9048409b-d5a2-435a-b735-70370705e668" /> - Enable direct top-up (or subscription if in trial) from AI chat <img width="333" height="215" alt="Screenshot 2026-04-17 at 22 52 00" src="https://github.com/user-attachments/assets/7a20c627-2806-4bcf-a037-b45752232be9" /> <img width="457" height="769" alt="Screenshot 2026-04-17 at 22 51 41" src="https://github.com/user-attachments/assets/d2a90c1b-271f-4fe9-8891-baeb2fabb86d" /> - Inform users if credit limit is reached - Banner <img width="1130" height="127" alt="Screenshot 2026-04-17 at 19 15 11" src="https://github.com/user-attachments/assets/30723e5e-c07e-462f-8eb8-e08f52bbab1c" />	2026-04-20 08:43:02 +00:00
Etienne	aecbc89a3f	Fix slow db query issue (#19770) ... https://github.com/twentyhq/twenty/pull/19586#discussion_r3074136617	2026-04-16 15:37:58 +00:00
Marie	bc28e1557c	Introduce updateWorkspaceMemberSettings and clarify product (#19441) ... ## Summary Introduces a dedicated **metadata** mutation to update **standard (non-custom)** workspace member settings, moves profile-related UI to use it, and aligns **workspace member** record permissions with the rest of the CRM so users cannot escalate visibility via RLS by editing their own member record. ## Product behaviour ### Profile and appearance (standard fields) - Users can still update **their own** standard workspace member fields that the product exposes in **Settings / Profile** (e.g. name, locale, color scheme, avatar flow) via the new **`updateWorkspaceMemberSettings`** mutation. - The mutation returns a **boolean**; the app **merges** the updated fields into local state so the UI stays in sync without refetching the full workspace member record. - **Locale** changes also keep **`userWorkspace`** in sync when a locale is present in the payload (including from the workspace `updateOne` path when applicable). ### Custom fields on workspace members - The dedicated metadata mutation **rejects** any **custom** workspace member field (and unknown keys). Those updates must go through the normal **object** `updateOne` pipeline, which is subject to **object- and field-level** permissions like other records. But since we don't have object- and field-level permission configuration for system objects yet, this permission is derived from Workspace member settings permission. - **Workspace member** is no longer exempt from ORM permission validation for updates merely because it is a **system** object. Users who **do not** have workspace member access (e.g. no **Workspace members** settings permission and no equivalent broad settings access on the role) **cannot** use `updateOne` on `workspaceMember` to change **custom** (or other) fields on their own row—even though that row is used for RLS predicates. - This closes a path where someone could widen what they can see by writing to fields that drive row-level rules. ### Who can change another member - Updating **another** user’s workspace member still requires **Workspace members** (or equivalent) settings permission, consistent with admin tooling.	2026-04-14 16:29:00 +00:00
Félix Malfait	307b6c94de	Align GraphQL error handling for billing and AI chat (#19690) ... ## What changed This refactor fixes AI chat error surfacing by aligning both the backend and frontend with the existing GraphQL error architecture instead of adding AI-local error translation. On the backend: - add a dedicated GraphQL billing exception path - register billing GraphQL handling globally for GraphQL requests - reuse the existing AI GraphQL interceptor path for agent/chat exceptions - keep billing status classification shared between REST and GraphQL - remove the earlier attempt to preserve `CustomException` metadata in the global GraphQL fallback On the frontend: - keep the original Apollo GraphQL error object in AI chat state - reuse shared Apollo/GraphQL helpers for user-facing messages and error-type checks - delete AI-specific error extraction helpers that duplicated generic GraphQL parsing - replace a few direct `extensions.subCode` call sites with a shared predicate ## Why it changed The original bug was that `BillingException` and AI exceptions thrown from chat were not being translated into GraphQL errors with the expected `extensions.subCode` and `extensions.userFriendlyMessage`, so the AI chat UI had nothing structured to inspect. An intermediate fix worked mechanically but pushed `CustomException` handling into the global GraphQL fallback, which blurred the intended layering. This PR moves the behavior back to explicit GraphQL edges. ## Root cause `AgentChatResolver` could throw `BillingException` and `AgentException`, but: - billing had a REST exception filter and no shared GraphQL equivalent - AI chat was not consistently using the same GraphQL exception translation path as the sibling AI resolver - the frontend chat UI had drifted into AI-specific error parsing instead of consuming the same structured Apollo errors as the rest of the app ## Impact - `BILLING_CREDITS_EXHAUSTED` is now preserved through GraphQL and can render the existing credits-exhausted UI in chat - `API_KEY_NOT_CONFIGURED` is preserved through the AI GraphQL path - AI chat now follows the same general GraphQL error consumption pattern as the rest of the frontend - billing GraphQL handling is less dependent on individual resolver authors remembering to add a filter ## Validation - `yarn jest --config packages/twenty-server/jest.config.mjs packages/twenty-server/src/engine/core-modules/billing/utils/__tests__/billing-graphql-api-exception-handler.util.spec.ts packages/twenty-server/src/engine/metadata-modules/ai/ai-agent/utils/__tests__/agent-graphql-api-exception-handler.util.spec.ts` - `yarn jest --config packages/twenty-front/jest.config.mjs packages/twenty-front/src/utils/__tests__/is-graphql-error-of-type.util.test.ts` - `npx oxlint --type-aware ...` on touched backend/frontend files - `npx prettier --check ...` on touched backend/frontend files ## Follow-up ideas - consolidate frontend GraphQL error helpers further so more existing direct `extensions.subCode` checks move to shared utilities - consider whether common GraphQL exception filter registration should live in a more explicit GraphQL-specific module instead of `CoreEngineModule` - add an end-to-end test for a real `sendChatMessage` GraphQL failure path in AI chat --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>	2026-04-14 18:31:59 +02:00
Félix Malfait	455022f652	Add ClickHouse-backed metered credit cap enforcement (#19586) ... ## Summary Implements a ClickHouse-backed polling system to enforce metered-credit caps for workflow executions, replacing reliance on Stripe billing alerts. The system re-evaluates tier caps against live pricing on every poll cycle, allowing price/tier changes to propagate immediately without recreating Stripe alert objects. ## Key Changes - **BillingUsageCapService**: New service that queries ClickHouse for current-period credit usage and evaluates whether a subscription has reached its metered-credit allowance (tier cap + credit balance) - `isClickHouseEnabled()`: Checks if ClickHouse is configured - `getCurrentPeriodCreditsUsed()`: Sums creditsUsedMicro from usageEvent table for a workspace within a billing period - `evaluateCap()`: Determines if usage has reached the allowance by reading live pricing from the subscription - **EnforceUsageCapJob**: Cron job that polls all active subscriptions and updates `hasReachedCurrentPeriodCap` on metered items - Runs every 2 minutes to keep cap enforcement in sync with live usage - Supports shadow mode (log-only) via `BILLING_USAGE_CAP_CLICKHOUSE_ENABLED` flag for safe rollout - Continues processing after per-subscription errors with detailed logging - **EnforceUsageCapCronCommand**: CLI command to register the enforcement cron job - **MeteredCreditService**: Extracted `extractMeteredPricingInfoFromSubscription()` as a pure function for callers that already hold the subscription with pricing loaded, avoiding redundant DB queries - **Configuration**: Added `BILLING_USAGE_CAP_CLICKHOUSE_ENABLED` flag to control enforcement mode (active vs. shadow) - **Constants**: Added `METERED_OPERATION_TYPES` to define which operation types count toward the metered product's credit cap ## Implementation Details - The service queries ClickHouse for the sum of `creditsUsedMicro` in the current billing period, matching Stripe meter semantics - Pricing is re-read on every evaluation, so tier changes propagate within one poll cycle without Stripe alert recreation - The cron job only updates the database when the cap state actually changes (no-op if already in the correct state) - Shadow mode allows safe validation before enabling enforcement; transitions are logged but not persisted - Comprehensive test coverage for both the service and cron job, including error handling and state transitions https://claude.ai/code/session_01VksTSrYLXJVCPVBQhQdBTe --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-04-13 21:17:41 +02:00
Charles Bochet	fa354b4c1c	Remove orphaned workspaceId column from BillingSubscriptionItemEntity (#19660) ... ## Summary - Removes the `workspaceId` column, `@Index()`, and `@ManyToOne` workspace relation from `BillingSubscriptionItemEntity` - The entity defined these fields but they don't exist in the actual database table, causing `column X.workspaceId does not exist` errors at runtime - The workspace relationship is already accessible through the parent `BillingSubscriptionEntity`	2026-04-13 17:53:33 +00:00
Charles Bochet	f6423f5925	Remove DataSourceService and clean up datasource migration logic (#19532) ... ## Summary - **Drop the `objectMetadata.dataSourceId` foreign key and index** via a 1-22 fast instance command — column kept nullable for data preservation - **Delete `DataSourceService`, `DataSourceModule`, and `DataSourceException`** — all code now uses `workspace.databaseSchema` directly - **Remove `IS_DATASOURCE_MIGRATED` feature flag** from default flags and all branching logic - **Simplify workspace/object creation pipelines** — `WorkspaceManagerService`, `DevSeederService`, and the object creation action handler no longer route through `DataSourceService` - **Keep `DataSourceEntity` and the `dataSource` table** for historical data — entity stripped of all ORM relations	2026-04-10 07:34:05 +00:00
neo773	8a10071253	add workspaceId to indirect entities (#19522) ... Required for `workspace:export` command --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-04-09 19:30:28 +00:00
Paul Rastoin	cd23a2bc80	Cleaning UpgradeCommand code flow (#19241) ... # Introduction Currently preparing the `UpgradeCommand` refactor, in this way started by cleaning up the existing avoiding unecessary dependencies to others services allowing easier readability and concern centralization for upcoming refactor The UpgradeCommand was extending up to five classes, overriding abstracted class and so on. It was also cascade injecting 3 services Introducing the `WorkspaceIteratorService` that centralize the commands set to run over a single workspace logic shared between both atomic upgrade command call and global upgradeCommand ## Tradeoff Duplicated `@Option` between both `UpgradeCommandRunner` and `WorkspaceMigrationRunner` ## Before ``` UpgradeCommand └─ extends UpgradeCommandRunner └─ extends ActiveOrSuspendedWorkspacesMigrationCommandRunner └─ extends WorkspacesMigrationCommandRunner (owns workspace iteration loop + ORM deps) └─ extends MigrationCommandRunner (dry-run, verbose, error handling) └─ extends CommandRunner (nest-commander) ``` ## Now ``` UpgradeCommand └─ extends UpgradeCommandRunner └─ extends CommandRunner (nest-commander) uses ─► Services (via composition) ``` ## Logging management At the moment all services are logging, in the best of the world only the runners should be doing so	2026-04-02 13:24:55 +00:00
Félix Malfait	77d4bd9158	Add billing usage analytics dashboard with ClickHouse integration (#18592) ... ## Summary This PR adds a comprehensive billing usage analytics feature that provides detailed breakdowns of credit consumption across execution types, users, resources, and time periods. The implementation includes a new ClickHouse-backed analytics service, GraphQL API endpoint, and a frontend dashboard component. ## Key Changes ### Backend - **New BillingAnalyticsService**: Queries ClickHouse for usage breakdowns by user, resource, execution type, and time series data - **BillingEventWriterService**: Writes billing events to ClickHouse for analytics while maintaining best-effort semantics (never blocks Stripe billing) - **ClickHouse Schema**: Added `billingEvent` table with 3-year TTL for storing detailed billing event data - **GraphQL Resolver**: New `getBillingAnalytics` query that aggregates usage data for the current billing period, protected by feature flag and billing permissions - **Enhanced BillingUsageEvent**: Added `userWorkspaceId` field to track per-user credit consumption - **AI Billing Integration**: Updated AI billing service to pass `userWorkspaceId` when recording usage events ### Frontend - **SettingsBillingAnalyticsSection**: New component displaying: - Usage breakdown by execution type with progress bars - Daily usage time series chart (28-day view) - Per-user credit consumption breakdown - Per-resource (agent/workflow) credit consumption breakdown - **SettingsUsage Page**: Dedicated page for viewing usage analytics - **GraphQL Query**: `GetBillingAnalytics` query with generated hooks - **Navigation**: Added Usage menu item in settings (feature-flagged) - **Mock Data**: Included screenshot mock data for preview/testing ### Feature Flag - Added `IS_USAGE_ANALYTICS_ENABLED` feature flag to control visibility and access to analytics features ## Implementation Details - Analytics data is queried in parallel for performance - ClickHouse writes are non-blocking to ensure billing operations never fail - Progress bars use dynamic coloring from a predefined palette - Time series visualization normalizes bar heights relative to max value - Empty state handling when no analytics data is available - Responsive UI with proper text truncation for long names https://claude.ai/code/session_01Y1EqrX6PFq3EJxJq89h7DF --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-03-23 10:28:23 +01:00
Etienne	9a850e2241	fix - handle invoice.paid webhook to recover unpaid subscriptions (#18770) ... Fixes https://github.com/twentyhq/private-issues/issues/432 ## Problem When a user's invoice goes unpaid, Stripe moves their subscription to `unpaid` status, and Twenty suspends the workspace. But if the user pays that invoice while a new billing period has started, Stripe has already generated a new **draft** invoice for that period. Since the draft isn't finalized or paid, Stripe doesn't reactivate the subscription — the workspace stays suspended indefinitely. ## What was missing - No handler for the `invoice.paid` Stripe webhook event - No mechanism to finalize draft invoices that accumulated during the `unpaid` period - No way to reset the workspace deletion countdown (`suspendedAt`) when a user shows payment intent ## What was added ### 1. `StripeInvoiceService` — new Stripe SDK wrapper - `listDraftInvoices(stripeSubscriptionId)` — lists all draft invoices for a subscription - `finalizeInvoice(invoiceId)` — finalizes a draft with `auto_advance: true` so Stripe auto-charges it ### 2. `INVOICE_PAID` enum value Added to `BillingWebhookEvent` so the controller can route it. ### 3. `processInvoicePaid()` in `BillingWebhookInvoiceService` New private handler that: - Fetches all draft invoices for the subscription - Filters to only those whose `period_end` is in the past (already overdue) - Finalizes each one (with error handling per invoice to avoid blocking the webhook) - If the workspace is suspended, resets `suspendedAt` to now (buys time before deletion) ### 4. Controller routing `INVOICE_FINALIZED` and `INVOICE_PAID` are now grouped in the same switch case, both calling `processStripeEvent(data, eventType)`, which forks internally in the service. ## Expected recovery flow User pays overdue invoice → Stripe fires invoice.paid → Handler finalizes past-due draft invoices (auto_advance: true) → Stripe auto-charges them → Subscription becomes active → customer.subscription.updated fires → Existing logic unsuspends workspace → suspendedAt refreshed (resets deletion countdown while payments cascade)	2026-03-20 14:19:53 +00:00
Marie	c1da7be6d7	Billing for self-hosts (#18075) ... ## Summary Implements enterprise licensing and per-seat billing for self-hosted environments, with Stripe as the single source of truth for subscription data. ### Components - **twenty-website** hosts the private key to sign `ENTERPRISE_KEY` and `ENTERPRISE_VALIDITY_TOKEN`. It communicates with Stripe to emit the daily `ENTERPRISE_VALIDITY_TOKEN` if the subscription is active, based on the user's Stripe subscription ID stored in `ENTERPRISE_KEY`. - **Stripe** is the single source of truth for subscription data (status, seats, billing). - **The client** (twenty-server + DB + workers) saves `ENTERPRISE_KEY` in the `keyValuePair` table (or `.env` if `IS_CONFIG_VARIABLES_IN_DB_ENABLED` is false) and the daily-renewed `ENTERPRISE_VALIDITY_TOKEN` in the `appToken` table. `ENTERPRISE_VALIDITY_TOKEN` is verified client-side using a public key to grant access to enterprise features (RLS, SSO, audit logs, etc.). ### Flow 1. When requesting an upgrade to an enterprise plan (from **Enterprise** in settings), the user is shown a modal to choose monthly/yearly billing, then redirected to Stripe to enter payment details. After checkout, they land on twenty-website where they are exposed to their `ENTERPRISE_KEY`, which they paste in the UI. It is saved in the `keyValuePair` table. On activation, a first `ENTERPRISE_VALIDITY_TOKEN` with 30-day validity is stored in the `appToken` table. 2. **Every day**, a cron job runs and does two things: - **Refreshes the validity token**: communicates with twenty-website to get a new `ENTERPRISE_VALIDITY_TOKEN` with 30-day validity if the Stripe subscription is still active. If the subscription is in cancellation, the emitted token has a validity equal to the cancellation date. If it's no longer valid, the token is not replaced. The cron only needs to run every 30 days in practice, but runs daily so it's resilient to occasional failures. - **Reports seat count**: counts active (non-soft-deleted) `UserWorkspace` entries and sends the count to twenty-website, which updates the Stripe subscription quantity with proration. Seats are also reported on first activation. If the subscription is canceled or scheduled for cancellation, the seat update is skipped. 3. `ENTERPRISE_VALIDITY_TOKEN` is verified server-side via a public key to grant access to enterprise features. ### Key concepts Three distinct checks are exposed as GraphQL fields on `Workspace`: | Field | Meaning | |---|---| | `hasValidEnterpriseKey` | Has any valid enterprise key (signed JWT **or** legacy plain string) | | `hasValidSignedEnterpriseKey` | `ENTERPRISE_KEY` is a properly signed JWT (billing portal makes sense) | | `hasValidEnterpriseValidityToken` | `ENTERPRISE_VALIDITY_TOKEN` is present and not expired (expiration depends on signed token payload, not on "expiresAt" on appToken table which is only indicative) | Feature access is gated by `isValid()` = `hasValidEnterpriseValidityToken || hasValidEnterpriseKey` (to support both new and legacy keys during transition). After transition isValid() = hasValidEnterpriseValidityToken ### Frontend states The Enterprise settings page handles multiple states: - **No key**: show "Get Enterprise" with checkout modal - **Orphaned validity token** (token valid but no signed key): prompt user to set a valid enterprise key - **Active/trialing but no validity token**: show subscription status with a "Reload validity token" action - **Active/trialing**: show full subscription info, billing portal access, cancel option - **Cancellation scheduled**: show cancellation date, billing portal - **Canceled**: show billing history link and option to start a new subscription - **Past due / Incomplete**: prompt to update payment or restart ### Temporary retro-compatibility: legacy plain-text keys Previously, enterprise features were gated by a simple check: any non-empty string in `ENTERPRISE_KEY` granted access. With this PR, we transition to a controlled system relying on signed JWTs. To avoid breaking existing self-hosted users: - **Legacy plain-text keys still grant access** to enterprise features. `hasValidEnterpriseKey` returns `true` for both signed JWTs and plain strings, and `isValid()` checks `hasValidEnterpriseKey` as a fallback when no validity token is present. - **A deprecation banner** is shown at the top of the app when `hasValidEnterpriseKey` is `true` but `hasValidSignedEnterpriseKey` is `false`, informing the user that their key format is deprecated and they should activate a new signed key. - **No billing portal or subscription management** is available for legacy keys since there is no Stripe subscription to manage. This retro-compatibility will be removed in a future version. At that point, `isValid()` will only check `hasValidEnterpriseValidityToken`. ### Edge cases - **Air-gapped / production environments**: for self-hosted clients that block external traffic (or for our own production), provide a long-lived `ENTERPRISE_VALIDITY_TOKEN` (e.g. 99 years) directly in the `appToken` table, with no `ENTERPRISE_KEY`. The daily cron will skip the refresh (no enterprise key to authenticate with), but the pre-seeded validity token will be used to grant feature access. No billing or seat reporting occurs in this mode. - **`IS_CONFIG_VARIABLES_IN_DB_ENABLED` is false**: if the user tries to activate an enterprise key but DB config writes are disabled, the backend returns a clear error asking them to add `ENTERPRISE_KEY` to their `.env` file manually. - **Canceled subscriptions**: the `/seats` endpoint skips Stripe updates for canceled or cancellation-scheduled subscriptions to avoid Stripe API errors. ### How to test - launch twenty-website on a different url (eg localhost:1002) - add ENTERPRISE_API_URL=http://localhost:3002/api/enterprise (or else) in your server .env - ask me for twenty-website's .env file content (STRIPE_SECRET_KEY; STRIPE_ENTERPRISE_MONTHLY_PRICE_ID;STRIPE_ENTERPRISE_YEARLY_PRICE_ID; ENTERPRISE_JWT_PRIVATE_KEY; ENTERPRISE_JWT_PUBLIC_KEY; NEXT_PUBLIC_WEBSITE_URL) - visit Admin panel / enterprise	2026-03-12 15:07:53 +01:00
Paul Rastoin	38ad0820c0	Fix server logs leak (#18423) ... # Introduction Previously the auth jwt stragegy would lod the whole user entity in the auth user context On an exception it would completely get logged on the pods ## Security layer - 0/ Updating the type system ( devxp only though ) - 1/ The jwt auth stragegy only load a specific sub set of the user entity - 2/ Sanitizing at the exception log level directly in case of a user context - 3/ Sanitizing at the console driver The last two sanitization could sound a bit redundant though they're still good fallback to keep in case new path occurs in the cb	2026-03-05 14:40:23 +01:00
Félix Malfait	012d819557	OAuth Client — Unified ApplicationRegistration, OAuth server, and frontend (#18267) ... ## Summary Consolidates three separate PRs (#18260, #18261, #18262) into a single unified branch with all review feedback addressed: ### New features - **ApplicationRegistration entity** — server-level registration for OAuth apps with encrypted server variables - **OAuth 2.0 server** — authorization code, client credentials, refresh token grants with PKCE support - **OAuth discovery endpoint** — `.well-known/oauth-authorization-server` metadata - **Frontend UI** — app registration details page with credential management, redirect URI editing, and server variable configuration - **CLI integration** — `twenty dev` auto-registers apps and stores OAuth credentials locally - **Authorize consent screen** — OAuth consent page at `/authorize` showing requested scopes ### Review feedback addressed **Renames (PR #18260):** - `appRegistration` → `applicationRegistration` (entity, tables, files, imports, GraphQL types) - `appRegistrationVariable` → `applicationRegistrationVariable` - `clientId` → `oAuthClientId`, `clientSecretHash` → `oAuthClientSecretHash`, `redirectUris` → `oAuthRedirectUris`, `scopes` → `oAuthScopes` **Security fixes (PR #18261):** - Fixed redirect URI validation bypass when `oAuthRedirectUris` is an empty array - Fixed workspace isolation in `clientCredentialsGrant` — now uses `find()` with explicit handling for multiple installations - Added error logging in refresh token `catch` block instead of silently swallowing **Code quality (PR #18262):** - Split `VersionDistributionEntry` into its own file (one export per file) - Split GraphQL queries and mutations into individual files with a shared fragment - Removed unused `OAuth` entry from `AuthProviderEnum` - Added loading state to `handleRotateSecret` - Removed 27 narration-style comments from test files - Added proper guards (`PublicEndpointGuard`, `NoPermissionGuard`) to controllers and resolvers ## Test plan - [ ] Verify `twenty dev` registers an app and stores OAuth credentials - [ ] Test OAuth authorization code flow end-to-end (authorize → token → API call) - [ ] Test client credentials grant - [ ] Verify redirect URI validation rejects requests when no URIs are registered - [ ] Verify app registration detail page renders correctly - [ ] Test secret rotation with loading state - [ ] Verify server variable editing and saving - [ ] Run `npx nx database:reset twenty-server` to validate migration Closes #18260, #18261, #18262 Made with [Cursor](https://cursor.com) --------- Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>	2026-02-28 14:07:49 +01:00
Etienne	7cbbd082e3	Billing - Fix (#18135) ... Context : https://github.com/twentyhq/private-issues/issues/425 Try to fix https://github.com/twentyhq/core-team-issues/issues/2158 --------- Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>	2026-02-23 12:13:19 +01:00
Félix Malfait	726b1373d9	fix: convert metered tier upTo from internal to display credits in listPlans (#18108) ... ## Summary - The `listPlans` GraphQL query was returning metered tier `upTo` values in internal credit units (1000x the display value), causing "Credits by period" and "Credit Plan" dropdowns to show "50M" instead of "50k" - Applied the existing `INTERNAL_CREDITS_PER_DISPLAY_CREDIT` (1000) divisor in `formatBillingDatabasePriceToMeteredPriceDTO`, matching the conversion already used in `getMeteredProductsUsage` resolver - Updated frontend mock data to reflect the corrected display-unit values ## Test plan - [x] Unit tests pass for `format-database-product-to-graphql-dto.util` - [x] Unit tests pass for `metered-credit.service` and `billing-credit-rollover.service` - [ ] Verify billing page shows correct credit amounts (50k, not 50M) for "Credits by period" and "Credit Plan" Made with [Cursor](https://cursor.com) --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>	2026-02-20 09:44:11 +01:00
Charles Bochet	9e21e55db4	Prevent leak between /metadata and /graphql GQL schemas (#17845) ... ## Fix resolver schema leaking between `/metadata` and `/graphql` endpoints ### Summary - Patch `@nestjs/graphql` to support a `resolverSchemaScope` option that filters resolvers at both schema generation and runtime, preventing cross-endpoint leaking - Introduce `@CoreResolver()` and `@MetadataResolver()` decorators to explicitly scope each resolver to its endpoint - Move most resolvers (auth, billing, workspace, user, etc.) to the metadata schema where the frontend expects them; only workflow and timeline calendar/messaging resolvers remain on `/graphql` - Fix frontend `SSEQuerySubscribeEffect` to use the default (metadata) Apollo client instead of the core client ### Problem NestJS GraphQL's module-based resolver discovery traverses transitive imports, causing resolvers from `/metadata` modules to leak into the `/graphql` schema and vice versa. This made the schemas unpredictable and tightly coupled to module import order. ### Approach - Added `resolverSchemaScope` to `GqlModuleOptions` via a patch on `@nestjs/graphql`, filtering in both `filterResolvers()` (runtime binding) and `getAllCtors()` (schema generation) - Each resolver is explicitly decorated with `@CoreResolver()` or `@MetadataResolver()` - Organized decorator, constant, and type files under `graphql-config/` following project conventions Core GQL Schema: (see: no more fields!) <img width="827" height="894" alt="image" src="https://github.com/user-attachments/assets/668f3f0f-485e-43f0-92be-4345aeccacb6" /> Metadata GQL Schema (see no more getTimelineCalendarEventsFromCompany) <img width="827" height="894" alt="image" src="https://github.com/user-attachments/assets/443913db-e5fe-4161-b0e7-4a971cc80a71" />	2026-02-11 10:05:24 +00:00
Charles Bochet	37b9a55382	Migrate metrics to prometheus (#17810) ... <img width="1316" height="611" alt="image" src="https://github.com/user-attachments/assets/277a63ed-2a8b-41ff-be78-281de8891579" />	2026-02-09 19:09:13 +01:00