Add Global search

[erwanMarmelab]

Problem

When a user looks for a past note, the only possible way to find it is by contact. If they remember only a term of the note but not the contact name, they’re obliged to check all contacts one by one

Solution

Add a search engine for notes & other content

• Open it from the app bar (an input-like button, or Ctrl/⌘+K) on desktop, or from the search icon in every mobile header.
• Results are grouped by type (contacts, companies, deals, tasks, contact notes, deal notes). Matched words are highlighted. When the match isn't in the result's name, an excerpt around it shows below; for notes and tasks, the excerpt replaces the start of the text.
• On desktop, the dialog stays pinned near the top and grows downwards as results arrive. On mobile, it takes the whole screen.
• On mobile, a contact result opens the contact's details tab, and a task result opens the contact's tasks tab.
• The mobile contact list drops its own name search in favour of the global one, and the refresh button now only shows on list pages (dashboard, contacts, tasks).

Desktop

Mobile

Contact list header	Search dialog

How

Each searchable table (companies, contacts, deals, tasks, contact notes, deal notes) carries a generated fts tsvector column with a GIN index (supabase/schemas/08_search.sql). Text is unaccented and split on non-alphanumerics, and every word of the query must match as a word prefix: tho and finds Thomas Anderson, helene finds Hélène.

A global_search(query, resources, max_results) RPC queries those indexes. It is security invoker, so RLS still applies, and anon cannot execute it. Each table returns its own newest max_results matches (capped at 200), then the union is cut to the global newest max_results. It also returns the searched fields as content, which the dialog uses for excerpts and highlighting.

• Date indexes let a common word (or a 2-letter prefix) stop at the first 50 matches instead of fetching and sorting every match.
• The RPC inlines the tsquery as a literal, so the planner sees the real term and picks per query between the GIN index (rare words) and the date index (common words). The fts columns of the large tables get statistics 10000 so it chooses well.

The frontend calls dataProvider.globalSearch() through react-query. Search results are kept out of the query cache the mobile app saves for offline use, and a failed search reports an error even while offline. The Supabase provider calls the RPC. The FakeRest provider emulates it with the same rules (same fields, word-prefix matching that folds accents and letters like ß or ł the way unaccent does, same limits), so the demo returns what production would.

The activity_log view serializes whole rows, so it now removes fts from them.

Why not a view

The first version used a search_index view (UNION ALL of the six tables, filtered with content ilike '%word%'). Its content column is computed over joins, so no index can serve it: each keystroke scanned every table, twice with the Prefer: count=exact that ra-data-postgrest sends on getList. Benchmark on 10k companies, 100k contacts, 20k deals, 200k tasks, 1.1M notes:

Term	View (page + count)	RPC
very common word	8.7 s + 7.3 s	23 ms
2-letter prefix	8.3 s + 6.9 s	20 ms
rare word	7.7 s + 7.8 s	22 ms
first + last name	7.7 s + 7.6 s	4 ms
no match	7.5 s + 7.5 s	4 ms

Why stored columns rather than expression indexes

GIN indexes on the search_document(...) expression would keep the tsvectors out of the rows, but the date-index path then rebuilds the tsvector of every row it walks (about 50 µs each), and the planner ignores the statistics of partial expression indexes. On the same data, rare words, first names and no-match queries went from 4–25 ms to 0.8–2.2 s.

Trade-offs

• Search is by word prefix, not substring: homas no longer finds Thomas.
• Fields of related records are not searched any more: a contact is not found by its company name, nor a note by its contact name. The user doc is updated accordingly.
• Storage: a tsvector is about twice the size of its text. On 1M notes, contact_notes grows from 585 MB to 1.9 GB, plus about 300 MB of GIN indexes.
• The fts column comes along when the app reads a table with select=* (notes, tasks, deals). It is excluded from the activity log, which shrinks activity responses by about 40%.
• The migration rewrites each table (ADD COLUMN ... STORED) under an exclusive lock: about 2.5 min for 1M notes.
• Writes cost about 0.25 ms more per note.

The migration was written by hand: supabase db diff could not run in the environment used. It applies cleanly with supabase db reset, the search functions use the exact supabase db dump format, and a schema diff against supabase/schemas shows no remaining difference.

Additional Checks

• The documentation is up to date
• Tested with fakerest provider (see related documentation)
• Tested with Mobile resolution

https://claude.ai/code/session_012Ksozv1ZM9XvohNqSYwvns

[pysnooLab]

Nice shape overall: reusing the activity_log UNION ALL pattern with security_invoker = on is the right call, the migration matches 03_views.sql exactly so there is no phantom diff, and the CommandDialog fix (moving DialogHeader inside DialogContent) is a genuine a11y improvement. Findings below were verified against a local Postgres and a running PostgREST rather than read off the diff.

Three of them break the feature's own stated use case, so worth a look before merge:

1. Multi-word search fails on 4 of the 6 arms. The parent name is displayed as subtitle but is absent from content, and the provider ANDs one ilike per word. "sourdough Thomas" returns nothing for a note on Thomas Anderson containing "sourdough".
2. Tasks monopolise the results. due_date is a future timestamp feeding the shared date DESC sort key, against past timestamps everywhere else, under a hard 50-row cap with no pagination. Measured: 6221 matches across 3 resources, 50 tasks returned, 0 of anything else. The tasks arm also has no where, so completed tasks are indexed too.
3. Errors are indistinguishable from empty results. The error from useGlobalSearch is unused, so a missing view or a network failure renders "No result found" with no notification.

Missing e2e coverage. e2e/ is untouched. The two added tests are welcome but cover only the FakeRest path: not the Supabase content@ilike filter, not Cmd+K, not navigation on select. The repo's e2e-conventions rule asks for an e2e spec on changes touching UI, filters, search or keyboard interactions, and exempts only pure CSS and migration-only changes. One spec asserting "a note word plus the parent contact name returns the note" would have caught findings 1, 2 and the mobile one at once.

Also worth noting: the docs checkbox is unchecked, and the behavior deserves a line in the user docs (min 2 characters, 50-row cap, no pagination, which resources are covered).

[pysnooLab]

The view filters where t.done_date is null, so for every task row it exposes the done_date branch is unreachable and created_at always resolves to due_date. Open tasks then carry future dates, and since search_index is sorted date DESC with a hard perPage: 50 and no pagination or ranking, they outrank every other result type. Grouping in the dialog is client-side, so it cannot recover rows the server never returned.

Not visible locally: a fresh install has an empty tasks table and the FakeRest generator uses past dates. It only shows up on existing deployments after upgrade.

Suggest coalesce("done_date", "created_at"), or dropping the backfill.

[erwanMarmelab]

Right, the done_date branch was dead — thanks.

Not taking coalesce(done_date, created_at) though: it lands every open task
on the migration instant, so they all tie at the top of the same date DESC
sort. Same crowding, dated today instead of 2027.

Now trusting due_date only once it has passed, falling back to the contact's
first_seen, clamped with least(..., now()). Measured on an open task due
2027-09-10: indexes at 2026-02-27 instead of the migration day.

[fzaninotto]

please let me test this one before merge

[fzaninotto]

UX feedback:

• the search dialog moves as the number of results changes. Since the feature is search-as-you-type, this results in a blinking screen. Attach the top of the dialog to a fixed position instead, and let it grow downwards as the number of results increases
• In the results, the search term doesn't always appear. For instance, if my search is found in the company description, only the company name appears.
• Also, the search term should be highlighted in the result.
• on mobile, the search dialog should use the entire page
• the search button in the app bar should look like a search input (even if it not one) for better UX. Also, beware of alignment with other buttons in the same app bar, and why is it using a grey color?
• when the result is a task, the link on mobile should be to the task tab in the user page