fix(cashier): fix Share account lookup false-negative in Transaction Entry
The partial/suffix match fallback was gated on "exactly one row came back from the list endpoint", but Share's /accounts/share list has no accountNo server-side filter at all — it always returns the full unfiltered list, so that guard could never pass and any non-exact account number search (e.g. shortened digits) reported "Account not found" even when the account existed. This fix (present on dev, lost in the earlier dev-merge's silent auto-resolve) drops the count gate and tries suffix-match then substring-match unconditionally.
This commit is contained in:
@@ -1633,12 +1633,14 @@ export class TransactionEntryComponent implements OnInit, OnDestroy {
|
||||
if (token !== this.searchToken) return; // stale result — newer search started
|
||||
const allItems: any[] = res?.pageItems ?? (Array.isArray(res) ? res : []);
|
||||
const f = cfg.matchField;
|
||||
// Exact match first, then suffix/partial match (backend may return by last-N-digits)
|
||||
// Exact match first, then suffix/partial match. Some account types (e.g. Share — its
|
||||
// list endpoint only accepts offset/limit, no accountNo filter at all) always return the
|
||||
// FULL unfiltered list rather than a server-side-narrowed one, so a partial match can't be
|
||||
// gated on "exactly one row came back" — it never would be for those types.
|
||||
const exactMatch = allItems.find((x: any) => x[f] === acNo);
|
||||
const partialMatch =
|
||||
!exactMatch && allItems.length === 1
|
||||
? allItems.find((x: any) => x[f]?.endsWith(acNo) || x[f]?.includes(acNo))
|
||||
: null;
|
||||
const partialMatch = !exactMatch
|
||||
? (allItems.find((x: any) => x[f]?.endsWith(acNo)) ?? allItems.find((x: any) => x[f]?.includes(acNo)))
|
||||
: null;
|
||||
const match = exactMatch ?? partialMatch ?? null;
|
||||
if (match?.id) {
|
||||
const clientIdFromSearch = acTyp !== 'GL' && match.clientId != null ? String(match.clientId) : null;
|
||||
|
||||
Reference in New Issue
Block a user