Unable to set global search field or change weight

[ManasMadrecha]

Bug Description

Currently only 4 fields are by default set as globally searchable fields for People object. If new indexed field is added, e.g. middle name or some website link, then even after being index, unable to add it to be globally searchable.

Also, no button to change the weight of the global search field.

Expected behavior

When we create an indexed field, then we should we able to add that field to globally searchable fields. And, also able to change the weight if needed

[sonarly[bot]]

🟡 Sonarly Analysis — Medium Severity

Search configuration is display-only

Global search only uses a fixed set of fields, while the settings UI displays those fields without providing controls to add fields or change weights.

Root Cause

Global search is backed by the generated searchVector column, not by arbitrary database indexes. SearchService ranks and filters exclusively against "searchVector" using ts_rank, ts_rank_cd, and the @@ to_tsquery(...) predicates [ref:packages/twenty-server/src/engine/core-modules/search/services/search.service.ts:297-328]. A custom BTREE/GIN index created through the data-model Indexes section accelerates reads on selected columns; it does not add those columns to searchVector [ref:d602f35cbdc55c59df5964f47b24f03574b8dbbc].

For People, the search-vector input is explicitly limited to four fields: name, emails, phones, and jobTitle [ref:packages/twenty-server/src/modules/person/standard-objects/person.workspace-entity.ts:28-33]. Fields such as a newly created middle-name or website field therefore remain absent from the generated vector even when a database index exists.

The settings UI reinforces this limitation rather than configuring it. SettingsObjectSearchSection parses the existing searchVector expression and only renders the fields already present in that expression [ref:packages/twenty-front/src/modules/settings/data-model/object-details/components/tabs/SettingsObjectSearchSection.tsx:49-97]. Each row hardcodes weight: 1, renders the value as plain text, and contains no add, remove, reorder, or weight-change handler [ref:packages/twenty-front/src/modules/settings/data-model/object-details/components/tabs/SettingsObjectSearchSection.tsx:86-92][ref:packages/twenty-front/src/modules/settings/data-model/object-details/components/tabs/SettingsObjectSearchSection.tsx:163-184]. The only mutation wired in this component changes the object's overall isSearchable flag [ref:packages/twenty-front/src/modules/settings/data-model/object-details/components/tabs/SettingsObjectSearchSection.tsx:124-129].

The underlying searchFieldMetadata table is only an entity/module foundation in this branch; its module has no providers or exports, and no GraphQL resolver or mutation path was found [ref:packages/twenty-server/src/engine/metadata-modules/search-field-metadata/search-field-metadata.module.ts:1-11][ref:packages/twenty-server/src/engine/metadata-modules/search-field-metadata/search-field-metadata.entity.ts:18-48]. Thus there is no backend operation for the UI to call.

The triggering state described in the issue is adding a custom database index to a previously non-searchable field. The custom-index management feature was introduced by d602f35cbdc55c59df5964f47b24f03574b8dbbc on 2026-05-25, but that feature affects database read performance only. It does not update the hardcoded People search-field list or the generated searchVector. The exact production deployment time and first occurrence cannot be established from the issue because no runtime telemetry or timestamp was provided.

Blame commit: 5f0d6553 by FelixMalfait — Add object type filter dropdown to side panel record searches (#18912)

Suggested Fix

Updated global search to derive its tsvector and ILIKE fallback expressions from all active searchable fields, including custom fields. This removes the dependency on the hardcoded/generated searchVector contents and makes custom fields searchable immediately after creation. Updated the data-model search settings section to list the actual active searchable fields instead of parsing the stale searchVector expression, and added a unit test covering custom searchable-field inclusion.

---

Analyzed by Sonarly · View full analysis

[FelixMalfait]

Search index isn't really linked to individual index fields so you shouldn't need to create indexes. It's very rare that there's a need to create individual indexes (only for clients with millions of records on a given table that run perf issues).

Agree search index by itself should be editable! @prastoin was working on that

[prastoin]

Hello there, indeed most the API mechanism already exists under the hood
Not a bug though just not implemented yet
Will tackle this during august

[ManasMadrecha]

Thanks. Had thought of adding search index because the searchable fields' input box said "search across indexable fields...". But @FelixMalfait you correctly pointed out no need for manually adding an index. Maybe, simply better wordings can be put inside the input box, e.g., "find searchable fields...".

@prastoin Thanks. That would be nice. Looking forward to it. 😊