[NotAbdelrahmanelsayed]

Summary

Enhances the in-cart customer search with faster, more forgiving lookup and clearer results.

What's included

• Clear-search (X) button — reset the query in one tap.
• Arabic-insensitive matching with highlighting — tokenized search that normalizes alef/ya/ta-marbuta variants, diacritics, and Arabic-Indic digits, with matched segments highlighted in the results (new POS/src/utils/searchText.js). Typing أحمد matches احمد and vice-versa.
• Top-customers suggestions — on focus, surfaces the most frequently selected customers (tracked per browser in localStorage under pos_customer_counts; these are not server-side counts or shared across devices).
• "Show All Customers in Search" setting — a new POS Setting (customer_search_show_all) to show up to 500 customers instead of the first 10–20 matches. Matching still runs over every cached customer in memory; only the rendered rows are capped, because thousands of rows make the dropdown janky. Typing narrows the list.
• Keyboard navigation — arrow-key nav auto-scrolls the highlighted row into view and preselects the top-ranked match; Enter selects it.

Tests & i18n

• Adds customerSearch.topCustomers.test.js (5 cases) covering the frequency ranking and tie-break.
• Adds Arabic (ar.csv) entries for every new user-facing string.

Verification

• npm run test:run — all tests pass.
• npm run build — compiles cleanly.
• Manual screenshot review against a live backend: confirmed the clear button, Arabic match highlighting, focus suggestions, results count, keyboard-nav preselection, and the settings toggle all render and behave correctly.

🤖 Generated with Claude Code

---

Reopens #308, which was auto-closed by the stale-PR bot for lack of recent activity. Updated against current develop after review.

[MohamedAliSmk]

Thanks for the PR — the Arabic-insensitive matching, result highlighting, clear button, and keyboard nav are a solid UX improvement for cashiers.

Before we merge, please:

1. Rebase / update onto current develop and confirm there are no conflicts with the existing cart customer search.
2. Double-check translations for every new user-facing string (Clear search, frequent/results labels, etc.) — some new strings look missing from ar.csv.
3. For customer_search_show_all, consider a soft cap or a note in the setting description. With thousands of customers, rendering the full list in the browser can get heavy even though filtering is in-memory.
4. Worth calling out in the PR body that pos_customer_counts is per-browser localStorage, not a server-side frequency metric.

Happy to re-review once it’s updated against latest develop.

[NotAbdelrahmanelsayed]

@MohamedAliSmk thanks for the review. All four points are done in 2a1f545:

1. Rebased onto current develop. I merged in develop. The cart customer search conflicted in three places, and I kept develop's behaviour in each one:
   • the phone icon for phone-number names
   • dir="auto" on the name
   • the changingCustomer state (Escape now resets it as well)
2. Translations. I checked every new __() string against ar.csv and all of them have Arabic entries: Clear search, Frequent Customers, All Customers, Results, and the setting's label and description.
3. customer_search_show_all. It now has a soft cap of 500 rendered rows. Matching still runs over every cached customer; only the rows drawn on screen are capped. The setting description says so in English and Arabic.
4. pos_customer_counts. The PR body states that it is per-browser localStorage, not a server-side frequency metric.

vitest run passes (43 files, 206 tests) and vite build compiles cleanly. Ready for another look.

[MohamedAliSmk]

Thanks @NotAbdelrahmanelsayed, I checked the four review points against 2a1f545 and they are all addressed: develop is merged with no conflicts, the Arabic strings are in ar.csv, the show-all list is capped at 500, and the PR body says the counts are per browser.

A few things are still needed before I can approve:

1. New setting may not reach existing sites. pos_settings.json gains customer_search_show_all, but its modified value is still 2026-06-03 15:54:09. Frappe only syncs the DocType on bench migrate when that timestamp changes. Please bump modified (or re-export the DocType), or add a patch.
2. CI is not green. The "Server" job failed during MariaDB setup (TLS/SSL error: SSL is required, but the server does not support it), so no server tests ran and the linter was skipped. This looks like a CI setup issue. Please re-run once it is fixed and make sure Server and Frappe Linter pass.
3. Enter picks a customer unexpectedly. With nothing selected, Enter now takes customerResults[0]. On focus with an empty search this selects a customer the cashier never chose. Please make the Enter auto-pick apply only when something has been typed.
4. Escape behavior. Escape now also blurs the input and re-emits select-customer with previousCustomer. Please confirm it works with the customer-change flow from feat: implement F4/F8/F9 keyboard shortcuts #366 and in offline mode.
5. Tests. Please add unit tests for searchText.js (normalization, matchSegments highlighting with Arabic diacritics, Arabic-Indic digits), and check that the new POS/vitest.config.js does not conflict with the existing test config.
6. Optional. Please squash-merge to clean up the merge commits, and drop the Claude-Session: line from the squash message.

Once 1 to 3 are done, this is fine to approve

[NotAbdelrahmanelsayed]

Thanks @MohamedAliSmk. All addressed in 3dee083:

1. Bumped modified in pos_settings.json so bench migrate syncs customer_search_show_all.
2. CI: the Server job fails because ubuntu-latest is now 26.04, whose mariadb-client 11.8 requires SSL. I opened fix(ci): pin Server job to ubuntu-24.04 #433 to pin it to ubuntu-24.04. I'll re-run once that lands.
3. Enter with nothing highlighted now picks the top match only when a query has been typed. Enter on a just-focused empty input selects nobody.
4. Tested in the browser: Escape after "change customer" restores the previous customer, both online and offline.
5. Added src/utils/__tests__/searchText.spec.js (normalization, matchSegments highlighting with Arabic diacritics and alef/ta-marbuta/ya forms, Arabic-Indic and Persian digits). The full vitest suite (44 files, 220 tests) passes with the new vitest.config.js, so it doesn't conflict with the existing specs.