Commit Graph

12992 Commits

Author SHA1 Message Date
Priyanshu Bartwal 6e7d8ef96c [Twenty-front]: Record table Header drag and drop functionality (#21304)
Closes #21303 and
https://github.com/twentyhq/core-team-issues/issues/151




https://github.com/user-attachments/assets/45cee1be-464f-467e-a1c0-cf5354ff87db

---------

Co-authored-by: Charles Bochet <charles@twenty.com>
2026-06-23 08:37:04 +02:00
Félix Malfait 46642c81c9 fix(front): unblock email verification on the central domain (blank modal) (#21980)
## Problem

After clicking the email-verification link on the central domain (e.g.
`app.twenty.com/verify-email?...`), a new user is left staring at a
**blank white auth modal** and onboarding never continues. The email is
actually verified — the user is just never moved off the verify-email
page.

## Root cause

`VerifyEmailEffect` (mounted on `/verify-email`) handles the
central/workspace‑agnostic domain like this:

```tsx
if (!isOnAWorkspace) {
  await verifyEmailAndGetWorkspaceAgnosticToken(emailVerificationToken, email);
  return enqueueSuccessSnackBar(successSnackbarParams);
}
```

It renders nothing of its own in this branch (`return <></>`) and relies
entirely on the auth hook to navigate.

The onboarding workspace-creation refactor (**#21641** "Let users pick
their workspace subdomain during sign-up", refined by **#21723**)
changed `navigateAfterMultiWorkspaceSignInUp`:

- **Before:** a user with `0` workspaces was sent through
`createWorkspace()`, which created the workspace and **redirected to the
workspace subdomain** — navigating away from `/verify-email`.
- **After:** for multi-workspace it now only does
`setSignInUpStep(SignInUpStep.WorkspaceCreation)` (the new
name/subdomain/logo form) — **no navigation**.

`signInUpStepState` is read **only by the `SignInUp` page**
(`/sign-in-up`), which renders `SignInUpWorkspaceCreationForm` for that
step. But the user is on `/verify-email`, whose route renders only
`VerifyEmailEffect` — which knows nothing about the step state and
returns an empty fragment. Nothing bridges the gap
(`usePageChangeEffectNavigateLocation` also won't redirect, because
`/verify-email` is whitelisted in `ONGOING_USER_CREATION_PATHS`), so the
user is stuck on an empty modal.

### Scope of the breakage
- **Broken:** new user, multi-workspace instance (Twenty Cloud central
domain), email verification enabled, signing up to create a workspace
(`0` workspaces). The `2+`-workspaces case (`WorkspaceSelection`) is the
same.
- **Not affected:** the single existing-workspace case (still does a
real `redirectToWorkspaceDomain`), the workspace-subdomain verification
path (`verifyEmailAndGetLoginToken` → `verifyLoginToken`), and
single-workspace self-host.

## Fix

After a successful workspace-agnostic verification, hand off to the
`SignInUp` page so it mounts and renders whatever step the hook just
set:

```tsx
if (!isOnAWorkspace) {
  await verifyEmailAndGetWorkspaceAgnosticToken(emailVerificationToken, email);
  enqueueSuccessSnackBar(successSnackbarParams);
  return navigate(AppPath.SignInUp);
}
```

This is intentionally scoped to `VerifyEmailEffect` (the only entry
point that lives on a route which doesn't host the sign-in-up step UI).
The in-app sign-in/sign-up callers of
`navigateAfterMultiWorkspaceSignInUp` are already on `/sign-in-up`, so
they're untouched — keeping their query params (invite tokens, billing
checkout, returnToPath) intact. For the single existing-workspace edge
case, the hook's redirect still wins.

## Testing

- New `VerifyEmailEffect.test.tsx`:
- central-domain success → navigates to `AppPath.SignInUp` + shows the
success snackbar;
- failure → does **not** hand off to `SignInUp` (error state is shown);
- workspace subdomain → workspace-scoped path is untouched (no
workspace-agnostic call, no `SignInUp` hand-off).
- `nx typecheck twenty-front` , `oxlint --type-aware` + `oxfmt` on
changed files .

https://claude.ai/code/session_017oVwW12hC42RdCgSKK8dFP

---
_Generated by [Claude
Code](https://claude.ai/code/session_017oVwW12hC42RdCgSKK8dFP)_

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21980?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-23 08:19:33 +02:00
Rashad Karanouh 24533b510c feat(twenty-partners): marketplace v2 — Application-driven matching workspace (#21816)
## Summary

Restructures the Twenty Partners app into an **Application-driven
matching workspace**: leads post briefs (Opportunities), partners browse
and **self-apply**, admins review applications and assign a winner. The
candidacy funnel lives on `Application.state`; the deal lifecycle lives
on the stock Opportunity `stage`.

Version **1.0.0** — **breaking**: removes the legacy `matchStatus` field
and the auto-match flow. Prod upgrade path is **uninstall → deploy →
install** (not an in-place upgrade).

## How "Apply" works — no workflow, no special permission

Partners apply by **creating an Application directly** from a listed
brief (a normal record write, governed by the Application object
permission). The `on-application-created` logic function (shipped in the
manifest) then resolves the partner from `createdBy`, sets `state =
APPLIED`, stamps `partner`/`partnerUser`/`lastActivityAt`, and dedupes
by (opportunity, partner).

- **No `WORKFLOWS` permission flag.** An earlier iteration used a manual
"Apply" workflow, but running a manual workflow requires the `WORKFLOWS`
flag, which **cannot be granted on an app-owned role** (the manifest
sync drops `role → permissionFlag` links, and the metadata API rejects
out-of-band grants on app roles). Self-apply via record-create sidesteps
this entirely and is prod-viable as-is.
- `Application.state` **defaults to `APPLIED`** so a partner never sees
a misleading "Invited" flicker while the async handler runs. Admin
invites set `INVITED` explicitly.

## ⚠️ Manual setup after install (per workspace)

1. **`yarn rls:configure`** — applies the partner row-level predicates
and verifies field-locks (predicates can't ship in the manifest).
Required for partner scoping.
2. **"Mark as Winner" workflow** — one manual-trigger workflow on
**Application** → *Update Record* that sets `Opportunity.partner`, which
drives the WON/BACKUP cascade. Admins run it (admins bypass the flag via
`canUpdateAllSettings`); equivalent to editing the Opportunity's
`partner` field directly. Steps in `src/workflows/README.md` (the
**Apply** section there is superseded by self-apply).

## What's included

- **Data model:** new `BACKUP` Application state; symmetric cascade
owned by `on-opportunity-partner-won` — assign → winner `WON`, other
applicants `BACKUP`; unassign → all reopen to `APPLIED`.
`Opportunity.partner` is the single source of truth.
- **Removed:** `matchStatus` field + `on-opportunity-auto-match` (dead).
Deal lifecycle now on the stock `stage`.
- **Partner row-level security (B7):** RLS predicates scope partners to
their own `Partner`/`Person`/`Company`/`Application` rows; `Opportunity`
is `(partnerUser IS me) OR (isListed = true)` so listed briefs are
visible to all partners; `Application` is `(partnerUser IS me) OR
(lastActivityAt IS EMPTY)` — the IS-EMPTY branch lets a partner's own
insert pass (partnerUser is stamped just after insert). Field-locks make
Opportunity `stage`/`amount` and most Application fields read-only for
partners (pitch stays editable). Applied via `yarn rls:configure`.
- *Trade-off:* an unstamped application (lastActivityAt null) is briefly
readable by any partner — sub-second window, permanent only if the
handler fails to stamp. Acceptable for an internal marketplace; the
front-component Apply path (below) would remove it.
- **Idempotency:** `on-application-created` dedupes duplicate
applications by (opportunity, partner).
- **Views & navigation**, reorganized into sections:
- **Partner Workspace:** Open Briefs · My Applications · My Profile · My
Deals
- **Matching Admin:** Briefs to Match · Deals (board) · Applications ·
Applications by Opportunity · All Opportunities · Follow-up Applications
· Follow-up Briefs
- **Partners:** per Stage · per Country · Partner Applications ·
Validated (per-group COUNT)
- Opportunity & Partner record **side panels** via FIELDS_WIDGET views
(surface relations incl. `applications`, so a brief shows all its
applications).

## Known issues / follow-ups

- **Pre-existing failing unit test (not introduced here):**
`on-partner-application-created › "posts a Discord embed when an
APPLICATION-sourced partner is created"` — the handler/test are
byte-identical to base; tracked separately.
- **Follow-up views** lack the "older than 7 days" staleness filter — no
confirmed relative date operand in this Twenty version (TODOs left in
the views).
- **Apply UX (future):** a front-component "Apply" button on the brief,
calling an authenticated `/s/apply-to-brief` logic function (runs as the
app), would replace the "create a record" entry point — nicer UX, and it
removes the RLS IS-EMPTY trade-off. Not required to ship.

## Testing

- Partner self-apply verified end-to-end as a partner (create
application from a brief → lands on `APPLIED`).
- Unit tests for the WON/BACKUP cascade + application handlers pass (the
one failing test above is the pre-existing, unrelated Discord handler).
- Lint clean (`oxlint`).

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21816?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-light.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
2026-06-23 05:53:00 +00:00
neo773 242b989c0e fix(emails): stop reply composer infinite re-render (#21935)
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21935?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-23 00:57:54 +02:00
Paul Rastoin a5aac3c21e Logic function handler name hardened validation (#21956)
# Introduction
Introduce centralized handlerName validation for the logic function
handlerName inside the flat logic function validator

Even if not safe by definition, avoid string interpolation inside the
local driver executor when retrieving the handler name from the parent
module

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21956?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-23 00:55:42 +02:00
Charles Bochet a884945aca fix(deps): remediate HIGH image vulns (multer, ws, nodemailer) (#21984)
## What

Clears the HIGH-severity AWS Inspector findings on the `twenty-server`
container image. All three have stable, in-range fixes — no prereleases.

| Package | From → To | CVE | Path |
|---------|-----------|-----|------|
| multer | 2.1.1 → **2.2.0** (resolution) | CVE-2026-5038, CVE-2026-5079
(DoS) | transitive via `@nestjs/platform-express` |
| ws | 8.20.1 → **8.21.0** (resolution) | CVE-2026-48779 | pinned by
`@nestjs/graphql` (8.21.0 already in tree) |
| nodemailer | 8.0.10 → **9.0.1** | GHSA-p6gq-j5cr-w38f | nested in
`imapflow`; bumped `imapflow` 1.3.6 → 1.4.2 which depends on nodemailer
9.0.1 |

## Notes

- **multer 2.2.0 is the stable fix.** The advisories
([CVE-2026-5038](https://advisories.gitlab.com/npm/multer/CVE-2026-5038/),
[CVE-2026-5079](https://advisories.gitlab.com/npm/multer/CVE-2026-5079/))
list both `2.2.0` and `3.0.0-alpha.2` as fixed; Inspector reported only
the `3.0.0-alpha.2` prerelease, but we stay on the stable 2.x line.
- **nodemailer:** the top-level dep was already `^9.0.1`; only
`imapflow`'s nested copy was stale. imapflow 1.4.0 still ships
nodemailer 8.0.10 and 1.4.1 ships 9.0.0 (< the 9.0.1 fix), so **1.4.2 is
the minimum** that pulls the patched nodemailer.
- Lockfile-only resolution for multer/ws (they're transitive); imapflow
is a direct dep bump. yarn.lock net-shrinks from deduping.

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21984?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-23 00:54:46 +02:00
Rashad Karanouh 6055262012 Deploy website only when twenty-website changes (#21977)
## Problem

Every push to `main` redeploys the website. `cd-deploy-main.yaml`
dispatches the infra `auto-deploy-main` fan-out, which unconditionally
triggered `deploy-website`. Since most PRs don't touch
`packages/twenty-website/**`, the majority were full, identical
Cloudflare builds — wasted CI and noise.

## Fix

Detect website changes here (using the existing reusable
`changed-files.yaml`) and pass the result as a `deploy_website` input on
the **single** `auto-deploy-main` dispatch:

- New `website-changed-files` job checks `packages/twenty-website/**`.
- The existing `auto-deploy-main` dispatch now carries `-f
deploy_website=<true|false>`.
- This repo keeps triggering **only** `auto-deploy-main` — it never
dispatches `deploy-website` directly. `twenty-infra` decides whether to
run the website deploy (per @FelixMalfait's review: the public repo
shouldn't be able to run arbitrary `twenty-infra` workflows directly).
- Server/front deploy is **unchanged** — still every merge.

## Paired change & merge order

Companion PR: **twentyhq/twenty-infra#747** — adds the `deploy_website`
input to `auto-deploy-main` and gates the website dispatch on it.

**Merge twenty-infra#747 FIRST**, then this one. (If this merges first,
it would pass an input the old `auto-deploy-main` doesn't accept,
failing the dispatch. Infra-first only delays website auto-deploys until
this lands — no breakage.)
2026-06-22 21:23:26 +02:00
martmull 1646bdf35e Add twenty-partners on internal ci apps (#21975)
as title

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21975?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-22 21:08:40 +02:00
mfamularopsyc d2083e7a1b Set OpenAI Responses store false for AI chat and agents (#20888)
## Summary

This PR sets `openai.store = false` for Twenty's `@ai-sdk/openai` AI
calls.

This follows the approach discussed in #20877: instead of adding a new
Twenty-specific Zero Data Retention config variable, OpenAI Responses
calls no longer rely on OpenAI-stored response/item references. This
should help Zero Data Retention organizations and may also avoid stale
persisted-item replay errors for non-ZDR OpenAI users.

Changes included:

- Adds a shared OpenAI provider-options helper that merges `openai.store
= false` for `@ai-sdk/openai` models.
- Applies the helper to AI chat `streamText` calls.
- Applies the helper to workflow/agent `generateText` calls.
- Preserves OpenAI encrypted reasoning metadata through DB/UI message
mappers so reasoning context can be replayed without stored OpenAI item
references.
- Does not add a new env/config variable.

Related to issue #20877.

## Behavior / Tradeoffs

This changes OpenAI Responses behavior for all Twenty OpenAI users, not
only ZDR users.

The intended benefit is that Twenty no longer depends on OpenAI-stored
response/item references. The main tradeoff is reduced provider-side
item-reference reuse for non-ZDR OpenAI users.

To reduce the impact for reasoning models, this PR preserves
`providerMetadata.openai.reasoningEncryptedContent` through message
persistence/replay so reasoning context can still be provided without
stored OpenAI item references.

## Tests

- Focused server Jest tests for OpenAI provider-options merging and
reasoning metadata mapping.
- Focused frontend Jest test for reasoning metadata mapping.
- `oxlint` and `oxfmt --check` on changed files.
- `git diff --check`.

---------

Co-authored-by: Charles Bochet <charles@twenty.com>
Co-authored-by: Etienne <45695613+etiennejouan@users.noreply.github.com>
2026-06-22 17:26:02 +00:00
martmull 2dc6034a6c Add twenty meeting bot to internal application ci (#21974)
- remove useless github-connector (validated with @charlesBochet)
-  add twenty-meeting-bot to internal apps
2026-06-22 18:47:30 +02:00
Raphaël Bosi 5f22908588 Decouple twenty-ui Avatar from app server-URL config (#21968)
Makes `twenty-ui`'s `Avatar` render the `avatarUrl` it receives instead
of building it from `window._env_`/`window.location` at module load, so
the library no longer depends on the app environment. URL resolution
moves to `twenty-front` via a `getAbsoluteImageUrl` helper applied at
the call sites.

Part of making twenty-ui a standalone library.
2026-06-22 18:38:00 +02:00
twenty-pr[bot] e59e102448 chore: bump version to 2.16.0 (#21973)
## Summary

- Moves current version to previous versions array
- Sets TWENTY_CURRENT_VERSION to the new version
- Updates TWENTY_NEXT_VERSIONS with the next minor version
- Bumps twenty-client-sdk, twenty-sdk, and create-twenty-app to the same
version

## Checklist

- [ ] Verify version constants are correct
- [ ] Verify npm package versions match

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21973?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: Github Action Deploy <github-action-deploy@twenty.com>
2026-06-22 18:22:41 +02:00
Marie 96a2987610 Fix/sanitize chart filters on save (#21958)
# Fix: sanitize chart filters referencing deactivated/deleted fields

## Summary

When a field used in a chart (graph) widget filter was later
**deactivated or deleted**, saving the page layout failed with a backend
error such as:

> Chart "...": One of the chart filters uses "...", but it was deleted.
Please remove or replace this filter rule.

This happened even after the user tried to remove the offending filter
rule, because the invalid filter could still end up in the saved
configuration. This PR makes invalid chart filters get cleaned up
reliably — both as the user edits filters and, as a safety net, at save
time.

## Root causes

- **Edit-time persistence kept invalid filters.** `handleFiltersUpdate`
persisted the current filter state to the page layout draft without
sanitizing it against the object's active fields. An invalid filter
(referencing a deactivated/deleted field) was re-saved on every update,
blocking the configuration from being accepted.
- **Save never enforced the cleanup.** `useSavePageLayout` serialized
the draft as-is. The "filters referencing deactivated/deleted fields
will be automatically removed on save" promise shown in the warning
banner was only honored reactively (when the filter panel was actively
edited), never at the actual save boundary. A chart whose filter panel
wasn't touched kept its stale invalid filter in the payload.
- **Query time treated inactive fields as valid.**
`useGraphWidgetQueryCommon` considered all fields (including inactive
ones) valid, so deactivated-field filters were never dropped when
running the chart query.

## Changes

### Edit-time (keeps draft and UI in sync as you edit)
- `ChartFiltersSettings` — sanitize filters in `handleFiltersUpdate`
before writing to the draft, dropping any filter whose `fieldMetadataId`
is not in the active-fields set.
- `dropChartRecordFiltersWithDeletedFields` — enhanced to also clean up
filter groups left orphaned once invalid filters are removed
(iteratively removing empty groups and re-parenting checks).
- `useGraphWidgetQueryCommon` — restrict valid field IDs to `isActive`
fields so deactivated-field filters are silently dropped at query
execution.
- `ChartFiltersDeletedFieldsWarning` — updated copy to mention both
deactivated and deleted fields.

### Save-time safety net (guarantees no invalid filter is ever
persisted)
- New `sanitizeChartFiltersInPageLayoutDraft` util — walks every chart
widget in the draft and drops record filters (and now-orphaned groups)
whose `fieldMetadataId` is not in the widget object's set of active
fields. It leaves non-chart widgets untouched and leaves filters intact
when the object metadata can't be resolved (avoids wiping valid filters
during metadata loading).
- `useSavePageLayout` — builds a `Map<objectMetadataId,
Set<activeFieldId>>` from `useObjectMetadataItems()` and sanitizes the
draft before converting it to the update input.

This layer only ever removes filters whose field is genuinely
deactivated/deleted — the exact set the backend rejects — and never
removes filters pointing at valid fields.

## Tests

- `dropChartRecordFiltersWithDeletedFields.test.ts` — extended coverage
for orphaned filter-group cleanup.
- `sanitizeChartFiltersInPageLayoutDraft.test.ts` — new: drops
deactivated/deleted-field filters on save, keeps valid filters, cleans
up orphaned groups, leaves non-chart widgets alone, and leaves filters
untouched when object metadata is unresolved.


<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21958?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: Charles Bochet <charles@twenty.com>
2026-06-22 18:15:33 +02:00
Thomas des Francs 6ce7d04f9d Fix field widget textarea focus reset (#21959)
Short description: Keeps the field widget textarea on a local draft
value while focused so record-store rewrites do not reset the active
caret.

# Before

Typing in an editor-mode text field can lose caret position when the
global record store is rewritten by an external record update/refetch.


https://github.com/user-attachments/assets/1ee7a819-2c27-4d09-aae5-814c2cf27181


# After

The focused textarea should preserve the in-progress draft and caret
while still updating sibling previews optimistically and flushing the
final value on blur.


https://github.com/user-attachments/assets/41832493-021f-46e8-bc75-722bbb1cd7b7



<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21959?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-22 17:45:49 +02:00
Charles Bochet b1ada79d72 fix(front): scope relation table widget via currentRecordId (#21965)
## Context

Follow-up to #21293 (merged). That PR added a bespoke
`relationTableFilter` to keep a relation field rendered as a
record-table widget scoped to the host record. It turns out to be
redundant.

## Why it's redundant

The relation table widget's view already carries an
`isCurrentRecordSelected` relation filter on the inverse field — it's
baked in by `useAddDraftViewForFieldRelationTableWidget` when the widget
is configured. That filter is resolved through the `currentRecordId`
that `FieldWidgetRelationTable` provides via
`RecordFilterValueDependenciesContext`, and
`turnRecordFilterIntoGqlOperationFilter` turns it into exactly `{
`${inverseField}Id`: { in: [recordId] } }`.

So the hand-built `relationTableFilter` duplicated a filter the existing
mechanism already produces from `currentRecordId`.

## Changes

- Remove `relationTableFilter` from
`RecordFilterValueDependenciesContext`
- Stop reading/applying it in `useFindManyRecordIndexTableParams` and
`useAggregateRecordsForRecordTableColumnFooter`
- Delete the `getRelationTableFilter` util and its test
- `FieldWidgetRelationTable` provides `currentRecordId` only

Net −263 lines; relies on the existing `isCurrentRecordSelected` +
`currentRecordId` scoping path.

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21965?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-22 17:09:28 +02:00
Raphaël Bosi 8553c574db Improve twenty-ui packaging for standalone publishing (#21946)
Quick packaging wins to move twenty-ui closer to a standalone
publishable library.

- Move `react`/`react-dom` to `peerDependencies` (`^19.0.0`) so
consumers provide a single React and we avoid duplicate-React bugs. They
stay in `devDependencies` for the in-repo build, and `vite.config.ts`
now derives the Rollup `external` list from peer deps too so React stays
externalized instead of bundled.
- Declare `type-fest` in `dependencies`. It was a phantom dep (resolved
only via root hoisting) and its types are referenced by the emitted
json-visualizer `.d.ts`, so standalone consumers need it.
- Move build-only `glob` to `devDependencies` and add `typescript` (both
used only by `generateBarrels.ts`).
- Make `tsconfig.json` self-contained by inlining the base compiler
options, and point the Vite `cacheDir`/`optimizeDeps.exclude` at
package-local paths.

Verified: typecheck, build (React confirmed externalized in `dist`, not
inlined), dts emission, and unit tests all pass.

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21946?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-22 15:09:25 +00:00
Charles Bochet 2276e12c12 fix(server): skip callRecordings widget in calendar-event page sync when field is absent (#21967)
## Context

On main's auto-upgrade, `SyncCalendarEventRecordPageCommand` (2.15.0
workspace command) failed for workspaces that don't have the
call-recording feature metadata, aborting the upgrade with:

```
Migration action 'create' for 'pageLayoutWidget' (universalIdentifier: f473b435-...) failed
Caused by: Field metadata not found for universal identifier: 48d6d151-... (calendarEvent.callRecordings)
```

## Root cause

The command always included the `callRecordings` page-layout widget.
That widget's configuration references the
`calendarEvent.callRecordings` relation field (`48d6d151`). Workspaces
that never had the `callRecording` object / relation field synced fail
transpilation with `ENTITY_NOT_FOUND`, and since one workspace failure
aborts the segment, the whole upgrade stops.

On the affected environment, ~half of active/suspended workspaces lack
both the `callRecording` object and the `calendarEvent.callRecordings`
field.

## Fix

Only add the `callRecordings` widget when the `callRecordings` field
actually exists in the workspace (checked via
`flatFieldMetadataMaps.byUniversalIdentifier`). This mirrors the
command's existing guard on the `calendarEvent` object. Workspaces
without the field still get the fields / participants / timeline
widgets; the callRecordings widget is simply skipped.

The view fields for the record page do not reference `callRecordings`,
so only the widget needed guarding.

## Test plan
- [x] `nx typecheck twenty-server`
- [x] `oxlint --type-aware` on the changed file: 0 errors
- [ ] CI

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21967?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-22 17:02:29 +02:00
martmull 6d7380dfec Remove unused call-recording application (#21966)
as title

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21966?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-22 17:00:53 +02:00
Charles Bochet 5f94ee3e02 perf(server): raise workspace local cache size and meter evictions (#21954)
## Context

The per-pod in-process workspace metadata cache
(`WorkspaceCacheService`) evicts by a fixed **1,000-entry count**. Each
workspace's cached metadata is ~1 MB (dominated by the flat
`field-metadata` map) over ~10–13 entries, so 1,000 entries ≈ only a few
dozen workspaces per pod. On a multi-tenant instance with far more
active workspaces, the L1 cache thrashes — LRU-evicting and re-fetching
the ~1 MB of maps from Redis on misses — and since the cache sits in one
AZ while pods span both, ~half of that transfer is billed cross-AZ. (In
prod this cache node serves ~2.6 TB/day.)

## What this does

- **Raise `MAX_LOCAL_CACHE_ENTRIES` 1,000 → 7,500** (~500 workspaces at
~1 MB each; server pods are 4 GiB / `--max-old-space-size=3500`, so this
stays well within the heap).
- **Add a `workspace-metadata-cache/local-eviction` counter**
(incremented by the number of entries dropped each time the cache hits
capacity) so we can see capacity-driven evictions in metrics and tune
the limit from real data rather than guessing.

Eviction stays **batched** (`MIN_EVICT_KEYS`), so the sort runs about
once per 100 inserts at steady state rather than on every write.

### Why count, not bytes
An earlier iteration bounded by measured bytes, but that required
`JSON.stringify`-ing every cached value (incl. the ~1 MB field-metadata
maps) on every write — meaningful CPU/GC overhead on the fill path. A
raised count cap avoids that entirely; the new eviction metric gives us
the signal to right-size it.

No change to cache semantics, hashing, or the Redis format.
2026-06-22 17:00:29 +02:00
Charles Bochet 4dd9253d01 perf(server): rate-limit the active event stream count scan (#21951)
## Context

`twenty_event_streams_live_total` (an observable gauge) calls
`getTotalActiveStreamCount()` →
`scanAndCountSetMembers('workspace:*:activeStreams')`, which runs a
full-keyspace `SCAN MATCH` over the entire Redis DB **on every metrics
scrape, on every pod**. `SCAN MATCH` walks every key (filtering only the
output), and the subscriptions namespace shares the node with the
workspace metadata cache (~190k keys in our prod), so this was the
dominant Redis command (billions of `SCAN` calls) to count a handful of
sets.

## What this does

Cache the count and refresh it via the scan at most once per
`ACTIVE_STREAM_COUNT_REFRESH_MS` (5 min) per pod, instead of on every
scrape. Steady-state scrapes return the cached value; the authoritative
scan still runs periodically so the gauge stays fresh.

Single-method change; no new Redis keys, no data-model changes.
2026-06-22 16:58:32 +02:00
Rashad Karanouh 5ce91e711c fix(website): render partner marketplace dynamically to stop profile 404s (#21963)
Fixes #21962

## Root cause

Partner data is materialized **at build time** from the live partners
API, and a build-time fetch failure is silently swallowed
(`fetch-live-marketplace-partners.ts` → `catch → return []`). One root
cause surfaces in two places:

- **All profile links 404 (the reported issue).**
`profile/[slug]/page.tsx` enumerates slugs in `generateStaticParams()` —
a build-time fetch — under the `[locale]` layout's inherited
`dynamicParams = false`. If that build-time fetch fails or returns
empty, **zero slugs are generated**, and because `generateStaticParams`
never re-runs at runtime and `dynamicParams=false` disables on-demand
generation, **every** `/partners/profile/[slug]` 404s until the next
deploy — even though the marketplace returns 20 partners client-side.
- **`/partners/list` intermittently renders empty.** The list page is
statically prerendered; the same build-time failure bakes an empty
marketplace and freezes it in the OpenNext/R2 cache.

This only reproduces on deployed builds: local dev renders on demand,
the env vars are present, and the partners API is reachable.

## Fix

Two route-segment config changes, no data-layer rewrite:

| File | Change | Effect |
|---|---|---|
| `(site)/partners/profile/[slug]/page.tsx` | `export const
dynamicParams = true` | Any slug renders on-demand at runtime where the
API is reachable. `generateStaticParams` becomes best-effort prewarm
instead of a 404 trap. Genuinely missing slugs still `notFound()`. |
| `(site)/partners/list/page.tsx` | `export const dynamic =
'force-dynamic'` | List is fetched at runtime, never baked empty at
build. The explicit `next: { revalidate: 300 }` on `/s/partners`
survives `force-dynamic` (`patch-fetch.js` only forces no-store when
there is *no* explicit fetch config), so responses stay cached and are
served stale on transient blips. |

## Verification

- `oxlint` + `oxfmt --check`: clean on both files.
- `jest src/partners-marketplace`: 36/36 pass.
- End-to-end behavior (static-vs-dynamic rendering) is a build/deploy
concern with no meaningful unit test — needs a deploy to confirm against
the live marketplace.

## Note / follow-up (out of scope)

Edge case left deliberately: if a real partner's *first-ever* request
lands during an API outage, its on-demand `notFound()` could cache for
~300s. Closing that means making the slug lookup distinguish "fetch
failed" from "not found" — a larger change than this fix.

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21963?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-22 14:54:21 +00:00
neo773 c608792aea feat: real-time email & calendar tabs on record pages (#21953)
emails and calendar tabs only refreshed on reload, unlike timeline. this
subscribes to the participant object (messageParticipant /
calendarEventParticipant) for the record's related people over the
existing sse stream and refetches on change.

relatedPersonIds is resolved server-side so any object with the tab
inherits it, no per-object code. resolver stays the source of truth so
visibility masking is untouched.
2026-06-22 14:27:09 +00:00
rcshetty3 068a8d4efe fix(front): keep relation field record tables scoped to the host record (#21293)
## Problem

When a relation field is added to a record page as a record **table**
widget
(Page Layouts → a `FIELD` widget with `fieldDisplayMode: TABLE` and a
`viewId`),
the table renders the **global** list of the related object instead of
only the
records related to the current record.

Steps to reproduce:
1. On a Company record page layout, add a to-many relation field (e.g.
`Opportunities`) as a widget and set its display mode to **Table** with
a view
   (so it shows columns).
2. Open a Company record.
3. The Opportunities table lists *all* opportunities in the workspace,
not just
   the ones linked to that company.

Note: when the same relation widget has **no** `viewId`, it is correctly
scoped
to the record — but then it can't render custom columns. So custom
columns and
relation-scoping were effectively mutually exclusive.

## Root cause

`FieldWidgetRelationTable` renders the related records through
`RecordTableWidgetRendererContent` using the widget's `viewId`. That
path loads
the view's filters and fetches the related object's records, but **never
applies
the relation filter** that constrains the table to the host record. With
a
`viewId` present, the table therefore shows the whole object.

The relation filter itself already exists elsewhere —
`RecordDetailRelationSection` builds
``{ `${inverseRelationFieldName}Id`: { in: [recordId] } }`` for its
aggregate.
It just isn't applied on the table path.

## Fix

- Add a pure helper `getRelationTableFilter()` that builds the
host-relation
  filter for a to-many relation field (morph-aware, mirroring
  `RecordDetailRelationSection`).
- `FieldWidgetRelationTable` computes this filter and passes it down via
the
  existing `RecordFilterValueDependenciesContext` (new optional
  `relationTableFilter`).
- `useFindManyRecordIndexTableParams` (rows) and
`useAggregateRecordsForRecordTableColumnFooter` (footer aggregates) AND
this
  filter into their queries.

The filter is scoped to the relation-table instance through the context
and
defaults to `undefined`, so **every other table (record index, kanban,
dashboards, …) is unaffected** — `combineFilters` / object spread treat
the
absent filter as a no-op. No backend changes.

## Tests

- New unit tests for `getRelationTableFilter` (to-many → foreign-key
filter;
to-one → none; unresolved relation type / field → none; morph relation;
  missing morph target names → none).
- `nx typecheck twenty-front`, `nx lint twenty-front`, and the new
  `nx test twenty-front` suite pass locally.

## Screenshots

Same record (a "Centre" with 0 related theory allocations and 34 related
orders), same page-layout (relation fields shown as Table widgets with a
view).

**Before** — with a `viewId`, the relation tables show the *global*
lists: the
Theory Allocations table is full of allocations belonging to *other*
records,
and Collateral Orders shows 60 (the whole object's first page) instead
of 34.

<!-- drag the BEFORE screenshot here -->

**After** — the same tables are scoped to the record: Theory Allocations
is
empty (this record has none) and Collateral Orders shows exactly its 34
orders,
with the view's columns (Status / Total Value / Date).

<!-- drag the AFTER screenshot here -->

## Verification

Verified on a self-hosted instance running the equivalent change (the
four
touched files are byte-identical on `main` and the latest release tag):
a
relation table widget with a `viewId` now shows only the host record's
related
rows **with** the view's columns, the footer aggregates match the
visible rows,
and the global record index is unchanged. Confirmed across records with
different related-record counts (e.g. a record with 34 related orders
shows 34;
a record with 1 shows 1; records with 0 show an empty table).

---------

Co-authored-by: Charles Bochet <charles@twenty.com>
2026-06-22 16:26:33 +02:00
Abdullah. c171c62099 chore(twenty-server): upgrade typeorm to 0.3.29 (#21957)
## Summary

Upgrades **typeorm `0.3.26` → `0.3.29`** and adapts the twenty-orm
`update`/`upsert` overrides to typeorm's newly-added
`options.returning`. Upgrading to resolve
[this](https://github.com/twentyhq/twenty/security/dependabot/1573)
alert.

## Why

`0.3.29` is the latest release compatible with
`@ptc-org/nestjs-query-typeorm` (peers `typeorm@^0.3.15`; the `1.x` line
has no compatible release, so it's blocked until that dependency moves).

## Changes

**`chore` — bump**
- `typeorm` patch descriptor `0.3.26 → 0.3.29` + `yarn.lock`.
- Local patch carried over **unchanged** (pure rename) — both hunks
(`PickKeysByType` nullable-awareness, `DeleteResult.generatedMaps`) are
still absent upstream in `0.3.29`, so it remains load-bearing.

**`refactor` — adapt overrides**
- `0.3.29` adds `options?: UpdateOptions` (carrying `returning`) to
`EntityManager`/`Repository` `update()`. The override must accept it at
the base-mandated position, so it's added as its **own dedicated
parameter** (not hidden inside `permissionOptions`), honoring
`options.returning` with a fallback to Twenty's permission-aware
`selectedColumns` (`'*'` default).
- The same merge is applied to `upsert()`, which already received
`UpsertOptions` but was dropping its `returning` field — so both write
methods now treat the option identically.
- Internal call sites + specs updated for the new parameter slot.

## Verification

- `nx typecheck twenty-server` — **0 errors**
- twenty-orm unit tests — **191 / 191 pass**
- `oxlint` / `oxfmt` — clean
2026-06-22 16:08:09 +02:00
Raphaël Bosi 6eb60f8a49 Add gallery screenshot to People Data Labs app (#21960)
Adds a marketplace gallery screenshot to the People Data Labs app.

- Adds `public/gallery/cover.png` (Companies table with enriched fields)
- References it via a new `screenshots` field in
`application-config.ts`, matching the convention used by the other
internal apps (Linear, Fireflies, Last Contact).

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21960?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-22 15:54:00 +02:00
Paul Rastoin 0b8368cd6c Refactor search vector field (#21947)
# Introduction
Refactoring the search vector field validation

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21947?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-22 13:44:52 +02:00
znn a08f424cc5 suport non aws providers 1 (#21927)
Title: Relax @IsAWSRegion validation constraint for custom S3-compatible
storage endpoints

Summary: This PR updates the @IsAWSRegion decorator to support
non-standard region slugs (e.g., fr-par) when a custom S3-compatible
storage provider is used.

Previously, the decorator enforced a strict regex
(/^[a-z]{2}-[a-z]+-\d{1}$/) for all region variables, which caused
runtime validation errors and worker crashes when users tried to
configure non-AWS providers like Scaleway or DigitalOcean that use
different region formats.

This change introduces a conditional check: If the property being
validated is STORAGE_S3_REGION and a STORAGE_S3_ENDPOINT is defined on
the configuration object, the strict regex constraint is bypassed, and
any non-empty string is accepted.

Changes Made
is-aws-region.decorator.ts: Updated the IsAWSRegionConstraint class to
accept args: ValidationArguments. Added logic to bypass the regex
validation if args.property === 'STORAGE_S3_REGION' and
object.STORAGE_S3_ENDPOINT is present.
TypeScript Typings: **The AwsRegion interface intentionally remains
strictly typed as `${string}-${string}-${number}`. This preserves strict
compile-time types for standard usage, while class-validator and
class-transformer gracefully handle the runtime relaxation during
environment variable loading.**

Testing
I have added below script to test this function

```
const { validate, ValidateIf } = require('class-validator');
const { IsAWSRegion } = require('./packages/twenty-server/dist/engine/core-modules/twenty-config/decorators/is-aws-region.decorator');

class TestConfig {
  constructor(region, endpoint) {
    this.STORAGE_S3_REGION = region;
    this.STORAGE_S3_ENDPOINT = endpoint;
  }
}

ValidateIf((env) => !env.STORAGE_S3_ENDPOINT)(TestConfig.prototype, 'STORAGE_S3_REGION');
IsAWSRegion()(TestConfig.prototype, 'STORAGE_S3_REGION');

const config = new TestConfig('fr-par', 'https://s3.fr-par.scw.cloud');
validate(config).then(errors => {
  if (errors.length > 0) {
    console.error('Validation failed:');
    errors.forEach(err => {
      console.error(`Property: ${err.property}`);
      console.error(`Constraints:`, err.constraints);
    });
  } else {
    console.log('Validation passed!');
  }
});

```


Screenshots

before
<img width="1210" height="188" alt="Screenshot_2026-06-22_12-51-51"
src="https://github.com/user-attachments/assets/4cd0613e-79bd-43db-8d90-5dd0f5341002"
/>

after
<img width="1394" height="152" alt="Screenshot_2026-06-22_12-52-28"
src="https://github.com/user-attachments/assets/e5287fb5-8462-46ce-a078-f5657dd689a5"
/>

Closes https://github.com/twentyhq/twenty/issues/21908



<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21927?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: Charles Bochet <charles@twenty.com>
2026-06-22 13:36:46 +02:00
martmull 3030b7d0e5 Add people-data-labs on internal ci apps (#21941)
Add people-data-labs to internal apps CI: remove from
CI_EXCLUDED_APPLICATIONS and unify config with
twenty-discord/twenty-slack.

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21941?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-22 13:36:33 +02:00
Raphaël Bosi e0fadfee7c Remove jotai from twenty-ui (#21937)
twenty-ui no longer depends on jotai, so its components work without a
consumer-provided jotai store (better practice for a shared UI library).
twenty-front keeps jotai; this is scoped to the library.

- **Avatar**: tracks image-load failure in local `useState` instead of a
global atom.
- **Icons**: the icon registry moved from a jotai atom to a React
Context. `IconsProvider` and `useIcons` keep identical signatures; the
context itself stays internal.
- Removed the unused `createState` helper, the `invalidAvatarUrlsAtomV2`
/ `iconsState` atoms, and `JotaiRootDecorator`; regenerated barrels and
dropped the `jotai` dependency.

No other package needs changes: nothing imports the removed symbols, and
`twenty-sdk` (which re-exports twenty-ui via `export *`) simply stops
surfacing the two leaked atoms on its next publish.

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21937?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-22 13:33:32 +02:00
Charles Bochet 003ad62f66 fix(server): surface nested QueryFailedError detail in upgrade error formatting (#21948)
## Context

While upgrading, a workspace migration failed with:

```
[Runner] [install-perf] migration failed after 20 action(s): Migration action 'create' for 'pageLayoutWidget' (universalIdentifier: f473b435-...) failed
```

The action names the failure but not *why* — unique violation? FK? which
key/row? The real cause is captured but was getting flattened away
before it reached anyone reading it.

## Root cause of the bad diagnostics

When a migration action fails, the action handler captures the real
error (typically a TypeORM `QueryFailedError` from `repository.insert`)
into
`WorkspaceMigrationRunnerException.errors.{metadata,workspaceSchema,actionTranspilation}`
and re-throws it intact. Caller-side formatters surface it — but
`formatUpgradeErrorForStorage` (read by the `upgrade-status` command)
flattened a nested `QueryFailedError` to just its `.message`, dropping
the PostgreSQL `code`, `detail` (the exact failing key/value) and
`query`.

## What this PR does

`formatUpgradeErrorForStorage` now **recurses** into nested causes, so a
wrapped `QueryFailedError` keeps its full driver detail.
Surfacing/logging stays a caller concern (the runner already produces
and re-throws the structured exception) — this PR only fixes the
formatter that was dropping detail. Added a unit test for the `create
pageLayoutWidget` unique-violation case.

### Stored upgrade error — before
```
Metadata error: duplicate key value violates unique constraint "IDX_..."
```

### After
```
Metadata error:
  [QueryFailedError] duplicate key value violates unique constraint "IDX_..."
  PostgreSQL code: 23505
  Detail: Key (universalIdentifier)=(f473b435-...) already exists.
  Query: INSERT INTO "core"."pageLayoutWidget" VALUES ($1)
```

## Scope

Diagnostics only — it surfaces the cause, it does not change migration
behavior. The underlying `create pageLayoutWidget` failure (likely a
unique/FK violation when upgrading existing workspaces, downstream of
#21673) is a separate follow-up once the exact cause is captured.

## Note / possible follow-up

`workspaceMigrationRunnerExceptionFormatter` (the GraphQL/app-install
surfacing path) has the same flattening issue — it reads
`error.errors.metadata.code`, but for a `QueryFailedError` the pg code
lives on `driverError.code`, so it falls back to `INTERNAL_SERVER_ERROR`
and loses `detail`. Left out of scope here; happy to fix in a follow-up
if wanted.

## Tests

- New unit test for a `QueryFailedError` nested in an `EXECUTION_FAILED`
exception; snapshots updated.
- `oxlint`, `oxfmt --check`, `nx typecheck twenty-server`, and the
affected jest suites pass.
2026-06-22 13:32:21 +02:00
martmull 64385842bb Add twenty-linear on internal ci apps (#21942)
Add twenty-linear to internal apps CI: remove from
CI_EXCLUDED_APPLICATIONS and unify config with
twenty-discord/twenty-slack.

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21942?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-22 13:14:56 +02:00
martmull 4b868f9b29 Add twenty-for-twenty on internal ci apps (#21944)
Add twenty-for-twenty to internal apps CI: remove from
CI_EXCLUDED_APPLICATIONS and unify config with
twenty-discord/twenty-slack.

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21944?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-22 13:07:18 +02:00
Abdul Rahman 02a966bb7f make mergeMany atomic and optimize relation/field-map handling (#21885)
Closes
[core-team-issue#2333](https://github.com/twentyhq/core-team-issues/issues/2333)

## Summary
Hardens and optimizes `CommonMergeManyQueryRunnerService`:

- **Atomicity**: wrap relation migration + duplicate deletion + survivor
update in a single transaction so a mid-merge failure rolls back fully
(previously failures were swallowed and could leave orphaned/half-merged
data).
- **Perf**: drop the redundant `find`-before-`update` in relation
migration (2N → N queries, no row hydration) and hoist
`buildFieldMapsFromFlatObjectMetadata` out of the per-field loops.

### Why a transaction (not parallelization)
The relation migrations could be parallelized with `Promise.all`, but
merge is a destructive operation: a partial failure leaves orphaned or
half-merged records. We prioritize correctness, so the steps run inside
one transaction.


<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21885?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: Félix Malfait <felix@twenty.com>
Co-authored-by: Charles Bochet <charles@twenty.com>
2026-06-22 13:05:06 +02:00
nitin eeca9cd42e fix(front): isolate record table dashboard widget filters on duplicate (#21936)
closes
https://discord.com/channels/1130383047699738754/1518291134382608394



https://github.com/user-attachments/assets/931e4e88-44e8-4634-a7f9-e0564bd80fff



<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21936?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-22 16:27:01 +05:30
martmull 8b9e3a0fc3 Add self-hosting on internal ci apps (#21940)
Add self-hosting to internal apps CI: remove from
CI_EXCLUDED_APPLICATIONS and unify config with
twenty-discord/twenty-slack.

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21940?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-22 12:33:38 +02:00
martmull b354df3c59 Add twenty-fireflies on internal ci apps (#21939)
Add twenty-fireflies to internal apps CI: remove from
CI_EXCLUDED_APPLICATIONS and unify config with
twenty-discord/twenty-slack.

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21939?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-22 12:30:45 +02:00
Marie 1eadef8ea0 fix(workflow): serialize object variables in resolved prompts (#21612)
## Problem

When a workflow passes a variable into a text input (e.g. an **AI
Agent** prompt) and that variable resolves to an object or array, the
resolved string contained `[object Object]` instead of the actual
content. The AI then received useless input.

## Cause

`resolveString` in the shared variable resolver builds the final string
with `String.prototype.replace`. When an embedded `{{variable}}`
resolved to an object, the replace callback returned the object
directly, which JS coerces to `"[object Object]"`. The rich-text
resolver had the same issue via `String(resolvedValue)`.

## Fix

When an embedded variable resolves to a non-null object (or array),
serialize it with `JSON.stringify` before inserting it into the
surrounding string. Primitive values keep their existing coercion
behavior, and the single-variable case (`{{message}}` with nothing
around it) still returns the raw object so non-string consumers are
unaffected.

Applied the same guard to both the plain and rich-text variable
resolvers for consistency.

## Tests

Added cases covering embedded object/array variables in both resolvers,
plus a guard test confirming a standalone `{{variable}}` still returns
the raw object.

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21612?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-22 09:56:01 +00:00
Kartik Pant eefae87296 fix: surface proper errors for People create/delete constraint violations (#21270)
## Summary

Fixes #21119 — `createPerson` / `deletePerson` mutations fail with a
generic `INTERNAL_SERVER_ERROR: "Data validation error."` instead of a
meaningful error, blocking core CRM record management.

## Root Cause

The `computeTwentyORMException` function in `twenty-orm` contains a
catch-all block that matches **every known Postgres error code** via
`Object.values(POSTGRESQL_ERROR_CODES).includes(errorCode)` and discards
all error detail, throwing:

```ts
throw new PostgresException('Data validation error.', errorCode);
```

This `PostgresException` is then converted by the GraphQL error handler
into `INTERNAL_SERVER_ERROR`, masking the real constraint violation.
Common mutations like `createPerson` that hit:
- **`NOT_NULL_VIOLATION` (23502)** — a required field is missing
- **`FOREIGN_KEY_VIOLATION` (23503)** — referenced record missing or
deletion blocked by a FK
- **`RESTRICT_VIOLATION` (23001)** — record deletion blocked by a
referencing row

...all silently surface as the same opaque `"Data validation error."`
with `INTERNAL_SERVER_ERROR`.

Already handled correctly before the catch-all:
- `UNIQUE_VIOLATION` → delegates to `handleDuplicateKeyError` 
- `INVALID_TEXT_REPRESENTATION` → `TwentyORMException(INVALID_INPUT)` 
- Query read timeout → `TwentyORMException(QUERY_READ_TIMEOUT)` 

## Fix

Add explicit handling **before** the catch-all for the four most common
data-integrity constraint errors, converting them to
`TwentyORMException(INVALID_INPUT)` with a clear user-facing message.
The GraphQL error handler then returns `BAD_USER_INPUT` (400) instead of
`INTERNAL_SERVER_ERROR` (500).

## Changes

###
`packages/twenty-server/src/engine/twenty-orm/error-handling/compute-twenty-orm-exception.ts`

Added specific handling for:
| Postgres Code | Constant | User-facing message |
|---|---|---|
| `23502` | `NOT_NULL_VIOLATION` | "A required field is missing. Please
provide all required values and try again." |
| `23503` | `FOREIGN_KEY_VIOLATION` | "This operation references a
record that does not exist or cannot be modified due to existing
relationships." |
| `23001` | `RESTRICT_VIOLATION` | "This record cannot be deleted
because it is still referenced by other records." |

## Before / After

**Before:**
```json
{
  "data": { "createPerson": null },
  "errors": [{
    "message": "Data validation error.",
    "extensions": { "code": "INTERNAL_SERVER_ERROR" }
  }]
}
```

**After (e.g. NOT_NULL_VIOLATION):**
```json
{
  "data": { "createPerson": null },
  "errors": [{
    "message": "A required field is missing. Please provide all required values and try again.",
    "extensions": { "code": "BAD_USER_INPUT" }
  }]
}
```

---------

Co-authored-by: Pantkartik <pantkartik@github.com>
Co-authored-by: Charles Bochet <charles@twenty.com>
Co-authored-by: Etienne <45695613+etiennejouan@users.noreply.github.com>
2026-06-22 11:45:25 +02:00
martmull cb5d64fefc Add twenty-exa application to internal app ci (#21882)
renamed exa to twenty-exa
add twenty-exa to ci check

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21882?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-22 11:36:33 +02:00
nitin 6237598a30 Fix meeting bot CalendarEvent field visibility and editability (#21883)
- Add the meeting bot preference field to the CalendarEvent record page
fields view.
- Use a Standard-app ownership gate for record field read-only logic.
- Allow app-owned and workspace-custom fields on system objects to
follow isUIEditable and permissions.

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21883?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-22 11:24:32 +02:00
martmull 584c567a7f Add twenty-discord on internal ci apps (#21928)
add twenty-discord to ci check

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21928?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-22 11:05:43 +02:00
Abdullah. c8813c3b6a fix(security): drop vulnerable postcss via styled-components bump (XSS) (#21932)
## fix(security): drop vulnerable postcss via styled-components bump
(XSS)

Resolves [Dependabot Alert
#1061](https://github.com/twentyhq/twenty/security/dependabot/1061).

### What

`postcss` `< 8.5.10` is affected by **XSS via an unescaped `</style>` in
its CSS stringify output** (Moderate). Patched in `8.5.10`.

### How — parent-bump, no resolution

The only consumer of the vulnerable `postcss@8.4.49` (exact-pinned) was
`styled-components`, which **dropped the postcss dependency in 6.4.0**.
This bumps `styled-components` `6.1.15`/`6.3.12 -> 6.4.2` within the
existing `^6.1.0` / `^6.1.11` ranges (a minor bump within v6) — removing
`postcss@8.4.49` from the tree **entirely**. The remaining postcss
copies are `8.5.14` / `8.5.15` (both `>= 8.5.10`). No `resolutions`
override.

### Verification

- No `postcss < 8.5.10` resolution remains.
- `styled-components` is not imported directly in twenty-front (used via
`twenty-front-component-renderer` + `@cyntler/react-doc-viewer`);
`typecheck twenty-front-component-renderer` passes.
- Lockfile-only change (styled-components family); `yarn install
--immutable` passes.
2026-06-22 14:02:44 +05:00
Priyanshu Bartwal 4c966bfc32 [Twenty-front]: Bunch of View Picker Fixes and improvements. (#21290)
While working on #21208, I found a few related improvements and fixes
that were worth including in this PR.

1. Improved View Picker UX:
- Added optimistic updates when selecting a view from both the
drag-and-drop view picker
- Added optimistic updates when editing view. Before it used to close
the whole dropdown.
- Added highlighting for the currently selected view.
- Before:



https://github.com/user-attachments/assets/469fc60c-e65f-4452-a5a4-7df6188ab19d


- After:


https://github.com/user-attachments/assets/d3b151c1-0c10-45e7-a796-b5e6061c898d



2. Remove Favorites from the View Picker
- Added support for removing a favorite directly from the view picker
without needing to open additional menus.
- Before:


https://github.com/user-attachments/assets/70437fb9-d4c1-488b-aab9-0ea92d1bad99



- After:


https://github.com/user-attachments/assets/442546bd-24ae-43d5-abe1-268ef3ff6475

---------

Co-authored-by: Charles Bochet <charles@twenty.com>
2026-06-22 10:56:34 +02:00
Abdullah. bb12f426fd fix(security): bump react-router to 6.30.4 via react-router-dom (open redirect) (#21931)
## fix(security): bump react-router to 6.30.4 via react-router-dom (open
redirect)

Resolves [Dependabot Alert
#1382](https://github.com/twentyhq/twenty/security/dependabot/1382).

### What

`react-router` `>= 6.7.0, < 6.30.4` has an **open redirect**: a
same-origin redirect with a path starting `//` is reinterpreted as a
protocol-relative URL (Moderate). Patched in `6.30.4`.

### How — parent-bump, no resolution

`react-router` is exact-pinned by `react-router-dom`, which is our
**direct** dependency (`^6.4.4` in twenty-front/ui/shared).
`react-router-dom 6.30.4` pins `react-router 6.30.4`, and our range
already permits it — so this refreshes `react-router-dom 6.30.3 ->
6.30.4` within range (and its internal `@remix-run/router` 1.23.2 ->
1.23.3). No `resolutions` override.

### Verification

- No `react-router`/`react-router-dom` `< 6.30.4` resolution remains.
- Patch-level bump; `typecheck twenty-front` passes.
- Lockfile-only change (react-router family only); `yarn install
--immutable` passes.
2026-06-22 10:55:02 +02:00
Abdullah. 6ae2170744 chore(deps): bump wrangler to 4.102.0 and drop the wrangler/esbuild resolution (#21930)
## chore(deps): bump wrangler to 4.102.0 and drop the `wrangler/esbuild`
resolution

Removes a now-redundant `resolutions` override (resolution **cleanup**,
identified by the resolutions audit). It does not close a Dependabot
alert — esbuild stays at `0.28.1` either way — but reduces the standing
override count by one, per the `//resolutions` policy of dropping each
entry once its parent ships a fixed range.

### What

The `wrangler/esbuild: 0.28.1` resolution existed because `wrangler`
exact-pinned a vulnerable esbuild (`0.27.3`). **wrangler 4.102.0 now
ships esbuild `0.28.1` natively**, and our workspaces declare `wrangler
^4.0.0`, so it resolves to the safe version on its own.

### How — parent-bump, then drop the override

- Bumped `wrangler` within `^4.0.0` to `4.102.0` (lockfile-only).
- Removed the `wrangler/esbuild` entry from `resolutions`.
- Updated the `//resolutions` doc: moved wrangler to the "fixed by
parent-bump" list and decremented the esbuild counts (seven → six
resolutions; six → five exact-pin parents).

### Verification

- No `esbuild 0.27.3` regression (wrangler 4.102.0 pins `0.28.1`); the
remaining six esbuild resolutions are unchanged.
- `//resolutions` doc is consistent with the `resolutions` object.
- Lockfile + package.json only; `yarn install --immutable` passes.
2026-06-22 10:26:15 +02:00
Charles Bochet 153e41e036 ci: block bot contributors from PR commit history (#21926)
## What

Adds a CI check (`Blocked Contributors Check`) that runs on every PR and
**fails** if any commit is attributed to a known bot — via the commit
author, committer, or a `Co-Authored-By:` trailer.

Goal: keep automated agents (Claude, Cursor, Copilot, …) out of Twenty's
contributor history.

## How

- On `pull_request` (`opened`, `synchronize`, `reopened`) it fetches all
PR commits via the GitHub API and matches author/committer name+email
and the full commit message (for trailers) against an editable
blocklist.
- Patterns target **bot identities** (emails / `[bot]` handles), **not**
bare first names — so a human contributor named "Claude" is *not*
flagged.
- On failure it emits `::error::` annotations naming the offending SHA +
what matched, plus remediation guidance (rebase with `--reset-author`,
strip trailers, force-push).

Current blocklist:

```
noreply@anthropic.com
@anthropic.com
cursoragent@cursor.com
copilot-swe-agent[bot]
```

Add a line to block another bot — no logic changes needed.

## Notes

- This workflow only *reports* a failed status. To actually block
merges, add **Blocked Contributors Check** as a required status check in
branch-protection rules for `main` (repo Settings → Branches).
- `@anthropic.com` also blocks any Anthropic-domain identity; narrow to
just `noreply@anthropic.com` if real Anthropic employees may contribute
under their work email.

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21926?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-22 09:37:13 +02:00
Abdul Rahman 1b7dc0367e fix(ai): gemini not working in ask ai (#21898)
Upstream issue: https://github.com/vercel/ai/issues/14369

Gemini 400s whenever a tool result contains JSON Schema `$ref`/`$defs`
(it reads `$ref` as a function declaration name and finds no match). We
hit this because `learn_tools` returns tool input schemas, and our
recursive filter schema emits `$ref`/`$defs`. Other providers accept it
fine, so this only blocks Gemini.

Adds a Google-only `wrapLanguageModel` middleware that serializes
ref-bearing tool results to text before they reach Gemini, so the
pointers travel as a string instead of structured keys. The model still
reads the full schema (same as the MCP path). Guarded so normal tool
results pass through untouched.


<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21898?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: Charles Bochet <charles@twenty.com>
2026-06-22 07:16:59 +00:00
Mani bharadwaj 3ad5259106 fix(twenty-server): remove uuid format from openapi pageInfo cursors (#21920)
## Summary

The OpenAPI schema for list responses declared `pageInfo.startCursor`
and `pageInfo.endCursor` with `format: 'uuid'`, but the API actually
returns base64-encoded cursor strings. This makes the documented schema
inconsistent with the real response and breaks client generators that
trust the `uuid` format.

Closes #20003

## Changes

- Removed `format: 'uuid'` from `startCursor` and `endCursor` in
`getFindManyResponse200`.
- Removed `format: 'uuid'` from `startCursor` and `endCursor` in
`getFindDuplicatesResponse200`.

## Verification

- `npx nx lint:diff-with-main twenty-server` passed.
- `npx oxlint` on the modified file passed with 0 warnings/errors.
- `npx nx jest twenty-server --testPathPattern=open-api/utils` passed
(11 tests, 4 snapshots).

Note: `npx nx typecheck twenty-server` and the default `nx test` target
hit pre-existing build errors in `twenty-ui` (unrelated Tabler icon/type
mismatches), so I used the project`s `jest` target for focused
verification.

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21920?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-22 08:38:58 +02:00
Félix Malfait 2abf9c2930 feat(workflow): Pick Record load balanced strategy (3/3) (#21902)
## Overview

Final PR in the Pick Record stack. Adds the **Load Balanced** strategy:
pick the candidate that currently has the *fewest related records*. This
is the "fair assignment" mode — e.g. assign a new company to the account
owner who currently owns the fewest companies, or route a lead to the
rep with the fewest open opportunities.

**Stacked on #21900** (which is stacked on #21899) — merge in order.
This PR's diff against `main` includes PRs 1 & 2 until they merge.

## What changed

- Widened the `strategy` enum to add `LOAD_BALANCED`, and added an
optional `loadBalance: { objectNameSingular, fieldName }` to the action
input.
- Editor: selecting **Load balanced** reveals a **Balance by** object
picker and a **Count by** field picker (the related object's many-to-one
relation fields).
- Executor: for each candidate, counts records of the chosen related
object whose chosen relation points at that candidate, then selects the
least-loaded one.

## How it works

Given pool = workspace members and config `{ objectNameSingular:
"opportunity", fieldName: "pointOfContact" }`, the executor counts, per
member, the opportunities whose `pointOfContact` is that member, and
picks the member with the lowest count.

## Design decisions & tradeoffs

1. **No persistent state — computed live each run.** Unlike round robin,
load balancing reads current data, so there's no cursor to store.
Correct by construction even under concurrency (each run recomputes
counts); the only caveat is two simultaneous runs can both see the same
"least loaded" candidate before either assignment lands (a small,
self-correcting skew), which is inherent to load-balancing and
acceptable.

2. **Count via per-candidate queries.** One filtered count per candidate
(`{ [relationField]: { id: { eq: candidateId } } }`), run in parallel.
For the realistic pool sizes this targets (a team), this is simple and
clear. A single `group_by` aggregate would scale better for very large
pools — noted as a future optimization, deliberately not done to keep
the logic obvious.

3. **Deterministic tie-break.** Candidates are pre-sorted by id (shared
with round robin), and the first minimum wins — so equal-load ties
resolve deterministically rather than arbitrarily.

4. **`Count by` lists all many-to-one relations of the chosen object**
(not filtered to those targeting the pool object). Keeps the editor
simple; picking an unrelated field just yields zero counts, which is
visibly wrong. Filtering options to relations that target the pool
object is a nice follow-up.

5. **Filter on the counted set** (e.g. only *open* opportunities) is
intentionally out of scope for this first cut — documented as a
follow-up.

## Testing

Added `pick-record-load-balanced-workflow.integration-spec.ts`: creates
two fresh companies (0 related opportunities each), attaches one
opportunity to the second, configures `LOAD_BALANCED` counting
opportunities by `company`, and asserts the step picks the **first**
company (0 < 1). Passes locally alongside the random and round-robin
tests (3 suites / 4 tests). `typecheck` + `lint:diff-with-main` green
for shared/server/front.

## The full stack

1. #21899 — Random (the action + the whole scaffold)
2. #21900 — Round robin (atomic Redis cursor)
3. this — Load balanced

Together these enable round-robin / load-balanced / random **assignment
workflows** in Twenty, composed via the standard variable picker (assign
the chosen record downstream with `{{step.<id>.id}}`).

https://claude.ai/code/session_01MuPWZsqf2bmQSevk6fRbX8

---
_Generated by [Claude
Code](https://claude.ai/code/session_01MuPWZsqf2bmQSevk6fRbX8)_

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21902?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-22 07:09:15 +02:00
github-actions[bot] 82f6597dc3 i18n - docs translations (#21923)
Created by Github action

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21923?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: github-actions <github-actions@twenty.com>
2026-06-21 22:53:14 +02:00