AB#129867 improve-search-functionality-in-summary-cards-grids

[GhaziAlibi]

Description

Fixes the global search in summary cards and grids returning every record instead of filtering by the searched string.

Root cause

The frontend searchFilters() helper emitted a sub-rule for every field of the resource, including date / datetime fields. When the searched string was not a parseable date (e.g. "2026-E00000017"), the backend's getDateForMongo() produced null boundaries, yielding { $gte: null, $lte: null } clauses inside the global-search $or. Those clauses matched every document where the date field was missing, so the $or effectively matched everything.

Fix

• Frontend (search-filters.ts): skip date / datetime / datetime-local rules unless the search string parses as a valid date.
• Backend (getFilter.ts): when expanding _globalSearch into an $or, drop any sub-filter containing a comparison against null / undefined / invalid Date (defense in depth).

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

• Manual — global search in a summary card
  1. Open a dashboard containing a summary card backed by a resource with date/datetime fields.
  2. In the search box, type a value that exists in only one record (e.g. an incrementalId like 2026-E00000017).
  3. Verify only the matching card is shown (before the fix, every record was returned).

Screenshots

Checklist:

• * I have set myself as assignee of the pull request
• * My code follows the style guidelines of this project
• * Linting does not generate new warnings
• * I have performed a self-review of my own code
• * I have put the ticket for review, adding the oort-frontend team to the list of reviewers
• * I have commented my code, particularly in hard-to-understand areas
• * I have put JSDoc comment in all required places
• * My changes generate no new warnings
• * I have included screenshots describing my changes if relevant
• * I have selected labels in the Pull Request, according to the changes with code brings
• I have made corresponding changes to the documentation ( if required )
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

More explanation

https://www.loom.com/share/05a716d61b9744faaf51fb304c21d1e5?sid=f87cf896-582a-4f76-93ae-8ceed801b145