## Context
Closes#15970
Select and Multi Select fields did not show up in the Zapier
integration.
## Root cause
`computeInputFields` only emitted input fields for an explicit
allow-list of field types and silently dropped everything else, so
`SELECT` and `MULTI_SELECT` were never surfaced.
On top of that, `SELECT`, `MULTI_SELECT` and `RATING` are **GraphQL
enums** in Twenty's API. Their values must be sent as unquoted enum
literals in a mutation (`stage: SCREENING`), but `handleQueryParams`
quoted every string value (`stage: "SCREENING"`), which produces an
invalid mutation. So even surfacing the fields would not have been
enough to create/update records.
## Changes
- Surface `SELECT` (string) and `MULTI_SELECT` (string list) as input
fields in `computeInputFields`.
- Fetch field `options` in the metadata query and expose them as Zapier
`choices` (`value -> label`) so users pick from the real options instead
of typing raw enum values.
- Emit enum field values **unquoted** in create/update mutations. This
is derived from the object schema in `crud_record` and threaded into
`handleQueryParams`. This also fixes `RATING`, which was silently broken
for the same reason.
## Tests
- `computeInputFields`: new test asserting `SELECT`/`MULTI_SELECT`
produce the right fields with `choices` and `list`.
- `handleQueryParams`: new test asserting enum values are emitted
unquoted (scalar and array).
```
Test Suites: 2 passed
Tests: 5 passed
```
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21509?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. -->
Closes the remaining lodash Dependabot alerts **without any
`resolutions` override** — by upgrading the parent packages that pinned
the vulnerable lodash. Every `lodash` in the tree now resolves to
**4.18.1**.
### Closes
- **#824 — `_.template` code injection (HIGH)**
- #823 / #385 — prototype pollution in `_.unset` / `_.omit`
### What changed (4 parents pinned vulnerable lodash 4.17.x; all
upgraded, no override)
- **`@stoplight/spectral-functions`** → 1.10.2 (in-range; now uses
`lodash ^4.18.1`)
- **`zapier-platform-core`** 15.5.1 → 19.0.0 — aligns with the
already-present `zapier-platform-cli ^19` (they were mismatched). v19
tightened the `Bundle` types, so 3 call sites now type their bundle as
`Bundle<InputData>` and the test bundle includes the new `meta` fields.
- **`@graphql-codegen`** → `cli 6.3.1`, `typescript 5.0.10`,
`typescript-operations 5.1.0`, `typed-document-node 6.1.8`. These depend
on `@graphql-codegen/plugin-helpers ^6.3.0`, the release that dropped
lodash. (Stayed on the 6.x/5.x line on purpose — 7.x changes generated
output far more.)
### About the generated-file changes — they are cosmetic, not real
changes
The codegen bump touches one generated file. **Verified there is zero
semantic change:**
- Only `src/generated-metadata/graphql.ts` changes.
`src/generated/graphql.ts` (data) and `src/generated-admin/graphql.ts`
(admin) are **byte-identical**.
- Same 1,638 type declarations before and after — none added, none
removed.
- After stripping whitespace and union pipes, the file is
**byte-for-byte identical** — no type, field, or union member changed.
The entire diff is one formatting change from
`typescript-operations@5.x`: multi-member union types are now printed
multi-line with a leading `|` instead of on one line — which TypeScript
treats identically:
```ts
// before
payload?: { …ObjectMetadata… } | { …Path… } | null
// after
payload?:
| { …ObjectMetadata… }
| { …Path… }
| null
```
Only metadata is affected because only its operations select GraphQL
union types. To keep generated types otherwise behavior-identical,
`defaultScalarType: 'any'` was added to the three codegen configs
(codegen 6 would otherwise default unmapped scalars to `unknown`).
### Verification
- `twenty-front` typecheck ✓, `twenty-zapier` typecheck ✓
- `yarn install --immutable` ✓ (passes the hardened 3-day age gate)
- CI green — including the `graphql:generate` freshness check, which
regenerates against the canonical schema and confirms the committed
output is exactly what codegen produces
- No `lodash@4.17.x` remains anywhere in `yarn.lock`
Supersedes #21411 (which closed these via a one-line resolution).
# Migrate Company and Person standard fields in preparation for the
enrichment app
## Why
Our standard `Person`/`Company` objects accumulated fields that aren't
generic to every
business, while missing a more universal revenue field that essentially
every CRM ships.
This PR makes the **Standard application** hold a tighter, more
universal set of fields,
and sets the stage for a follow-up PR that introduces a **People Data
Labs enrichment app**
to populate them.
## What changes
### Standard fields
**Demoted (Standard → Workspace Custom application)** — not generic
enough to ship as standard:
| Object | Field | Type |
| ------- | ------------------------------ | -------- |
| Company | annualRecurringRevenue (ARR) | CURRENCY |
| Company | employees | NUMBER |
| Company | idealCustomerProfile (ICP) | BOOLEAN |
| Company | xLink (X/Twitter) | LINKS |
| Person | xLink (X/Twitter) | LINKS |
| Person | city | TEXT |
**Added (new generic Standard field)** — present in
Salesforce/HubSpot/Zoho, PDL-populatable:
| Object | Field | Type |
| ------- | ------------- |
-------------------------------------------------------- |
| Company | annualRevenue | CURRENCY (generic total revenue; replaces
the niche ARR) |
### Behavior by workspace
* **New workspaces:** demoted fields are gone; `annualRevenue` is
**active**.
* **Existing workspaces:** demoted fields are **preserved as active
custom fields, data intact**;
`annualRevenue` is created **inactive (opt-in)** with its column ready,
so a later activation
is a metadata-only toggle.
### Upgrade commands (v2.9)
Three idempotent, per-workspace commands, run in timestamp order:
1. **`upgrade:2-9:move-demoted-standard-fields-to-custom-application`**
(1799000040000) —
re-owns the 6 demoted fields to the workspace custom application
(`isCustom = true`,
new `applicationId` + fresh `universalIdentifier`), keeping their data
and active state.
2. **`upgrade:2-9:rename-conflicting-custom-fields`** (1799000045000) —
if a workspace already
has a *custom* field named `annualRevenue`, renames it to
`annualRevenueCustom`
(data preserved via column rename) so the standard field can be added.
Skips non-custom matches.
3. **`upgrade:2-9:add-inactive-generic-standard-fields`**
(1799000050000) — creates
`Company.annualRevenue` on existing workspaces as inactive, guarded to
skip workspaces
missing the target object or where the name is still taken.
**Failure model:** the workspace iterator isolates failures per
workspace (one workspace failing
never affects others); within a workspace the runner records per-command
status and resumes on the
next run, and every command is idempotent, so partial runs self-heal.
### Supporting changes
* **Field-option color palette:** widened the `TagColor` union
(`twenty-shared` `FieldMetadataOptions`
+ the field-metadata `options.input` DTO) from 10 colors to the full
theme palette, benefiting any
future SELECT/MULTI_SELECT field.
* **Dev seeder:**
* The default "Annual Recurring Revenue" dashboard widget now points at
the generic
`annualRevenue` field (renamed to "Annual Revenue").
* Removed the "Companies by Size (Stacked by City)" widget (relied on
the demoted `employees`).
* `employees` is dropped from company data seeds and re-added as a
**custom** field seed, so dev
workspaces still get an `employees` column matching the demoted
behavior.
### Cleanup
Front-end record types (`Company.ts`/`Person.ts`), the
`getDisplayNameFromParticipant` test mock,
metadata integration specs, the Zapier `crud_record` test, and the
regenerated
`get-standard-object-metadata-related-entity-ids` snapshot.
## ⚠️ Breaking change (intentional)
Removes standard fields `Company.annualRecurringRevenue`,
`Company.employees`,
`Company.idealCustomerProfile`, `Company.xLink`, `Person.xLink`, and
`Person.city` from the core
GraphQL schema (replaced by `Company.annualRevenue`).
This is why the breaking-changes check reports a large number of
removals — `graphql-inspector`
flags any removed object field plus its derived
aggregate/order-by/filter/update types.
**Mitigation:** the
`upgrade:2-9:move-demoted-standard-fields-to-custom-application` command
re-owns these fields as custom fields per workspace, preserving their
name and data, so existing
tenants keep working. New workspaces won't have them.
## Summary
- Removes the deprecated `RICH_TEXT` (V1) field metadata type from the
codebase entirely
- Adds a 1.20 upgrade command that migrates existing `RICH_TEXT` fields
to `TEXT` in `core.fieldMetadata`
- Cleans up ~70 files across `twenty-shared`, `twenty-server`,
`twenty-front`, `twenty-sdk`, and `twenty-zapier`
## Context
`RICH_TEXT` was a legacy field type that stored rich text as a single
`text` column. It was already **read-only** — writes threw errors
directing users to `RICH_TEXT_V2` instead. `RICH_TEXT_V2` is the current
approach: a composite type with `blocknote` (editor JSON) and `markdown`
subfields. Keeping the deprecated type added maintenance burden without
any value.
Since the underlying database column type for `RICH_TEXT` was already
`text` (same as `TEXT`), the migration only needs to update the metadata
— no data migration or column changes required.
## Changes
### Upgrade command (new)
- `1-20-migrate-rich-text-to-text.command.ts` — runs `UPDATE
core."fieldMetadata" SET "type" = 'TEXT' WHERE "type" = 'RICH_TEXT'` per
workspace, with cache invalidation
### Enum & shared types
- Removed `RICH_TEXT` from `FieldMetadataType` enum
- Removed from `FieldMetadataDefaultValueMapping`,
`isFieldMetadataTextKind`
### Server (~30 files)
- Removed from type mapper (scalar, filter, order-by), data processors,
input transformer, filter operators, zod schemas, column type mapping,
searchable fields, RLS matching, OpenAPI schema, fake value generators
- Removed from field creation flow and field metadata type validator
- Updated dev seeder Pet `bio` field to `TEXT`
- Cleaned up mocks, snapshots, integration tests
### Frontend (~25 files)
- Deleted: `RichTextFieldDisplay`, `isFieldRichText`,
`isFieldRichTextValue`, `useRichTextFieldDisplay`
- Removed from `FieldDisplay`, `usePersistField`, `isFieldValueEmpty`,
`isRecordMatchingFilter`, `generateEmptyFieldValue`,
`isFieldCellSupported`, spreadsheet import, workflow fake values
- Removed from settings types, field type configs, and field creation
exclusion list
- Updated tests, mocks, and stories
### SDK & Zapier
- Removed from generated GraphQL schema and TypeScript types
- Removed from Zapier `computeInputFields`
- Fixes self host application
- add new telemetry information
- add serverId to identify a server instance
- remove .twenty from git tracking
- tree-shake "twenty-sdk" usage in built logic functions and front
components
- fix "twenty-sdk" version usage
- fix twenty-zapier cli
---------
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Changes the default behavior for settings navigation items to stay
active when navigating to sub-pages.
**Problem:**
- Navigation items like "Data Model" and "Webhooks" were not staying
highlighted when navigating to detail pages
- This was because `matchSubPages` defaulted to requiring exact path
matches
**Solution:**
- Updated logic to make sub-page matching the default behavior (`end:
item.matchSubPages === false`)
- Only "Accounts" explicitly sets `matchSubPages: false` for its custom
sub-item navigation
- Removed redundant `matchSubPages: true` declarations throughout the
codebase
**URL Changes:** -- checked with @Bonapara
- `/settings/workspace` → `/settings/general`
- `/settings/workspace-members` → `/settings/members`
- `/settings/api-keys` → `/settings/apis`
- `/settings/developers/webhooks` → `/settings/webhooks`
before:
https://github.com/user-attachments/assets/56b94a49-9c31-4bb5-9875-ec24f4bc4d1e
after:
https://github.com/user-attachments/assets/38742599-c045-44d1-8020-56f3eacca779
---------
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
# Introduction
In this PR we've migrated `twenty-shared` from a `vite` app
[libary-mode](https://vite.dev/guide/build#library-mode) to a
[preconstruct](https://preconstruct.tools/) "atomic" application ( in
the future would like to introduce preconstruct to handle of all our
atomic dependencies such as `twenty-emails` `twenty-ui` etc it will be
integrated at the monorepo's root directly, would be to invasive in the
first, starting incremental via `twenty-shared`)
For more information regarding the motivations please refer to nor:
- https://github.com/twentyhq/core-team-issues/issues/587
-
https://github.com/twentyhq/core-team-issues/issues/281#issuecomment-2630949682
close https://github.com/twentyhq/core-team-issues/issues/589
close https://github.com/twentyhq/core-team-issues/issues/590
## How to test
In order to ease the review this PR will ship all the codegen at the
very end, the actual meaning full diff is `+2,411 −114`
In order to migrate existing dependent packages to `twenty-shared` multi
barrel new arch you need to run in local:
```sh
yarn tsx packages/twenty-shared/scripts/migrateFromSingleToMultiBarrelImport.ts && \
npx nx run-many -t lint --fix -p twenty-front twenty-ui twenty-server twenty-emails twenty-shared twenty-zapier
```
Note that `migrateFromSingleToMultiBarrelImport` is idempotent, it's atm
included in the PR but should not be merged. ( such as codegen will be
added before merging this script will be removed )
## Misc
- related opened issue preconstruct
https://github.com/preconstruct/preconstruct/issues/617
## Closed related PR
- https://github.com/twentyhq/twenty/pull/11028
- https://github.com/twentyhq/twenty/pull/10993
- https://github.com/twentyhq/twenty/pull/10960
## Upcoming enhancement: ( in others dedicated PRs )
- 1/ refactor generate barrel to export atomic module instead of `*`
- 2/ generate barrel own package with several files and tests
- 3/ Migration twenty-ui the same way
- 4/ Use `preconstruct` at monorepo global level
## Conclusion
As always any suggestions are welcomed !
# Default address 🗺️ country & Phone ☎️ country
We add the ability to add a Default address country and a default Phone
country for fields in the Data model.
fix#8081
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
- fix webhook.operation format change from august 2024 not spread in
twenty-zapier
- added a comment so it does not happen again
- add a fix for the new webhook.operations column that would produce
another issue
* Add folder for api settings
* Init create api key page
* Update create api key page
* Implement api call to create apiKey
* Add create api key mutation
* Get id when creating apiKey
* Display created Api Key
* Add delete api key button
* Remove button from InputText
* Update stuff
* Add test for ApiDetail
* Fix type
* Use recoil instead of router state
* Remane route paths
* Remove online return
* Move and test date util
* Remove useless Component
* Rename ApiKeys paths
* Rename ApiKeys files
* Add input text info testing
* Rename hooks to webhooks
* Remove console error
* Add tests to reach minimum coverage
Charles Bochet
